Wekan: SSRF filter bypass via DNS-resolving hostname in outgoing webhooks (incomplete fix of CVE-2026-53446)
Wekan is open source kanban built with Meteor. From 8.36 until 9.74, the outgoing webhook Integration URL validator in models/integrations.js checked only the literal URL.hostname against regular expressions, so DNS names such as 169-254-169-254.nip.io passed that first-line check. The delivery path's fetchSafe guard already blocked the reported IPv4 destination, but its separate IPv4-only resolver and duplicated blocklist created inconsistent all-address-family enforcement and drift risk between input-time and connection-time validation. Version 9.74 makes server/lib/ssrfGuard.js resolve all addresses with `dns.lookup({ all: true })`, validate every result through the shared isIpBlocked logic, pin the connection, and block redirects. This issue is fixed in version 9.74.
- Products
- Not specified
- Affected versions
- Not specified
- Fixed versions
- Not specified
- CVEs
- CVE-2026-68558
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 3 Nov 2026, 01:15 UTC · Revision 1
Source evidence
Wekan: SSRF filter bypass via DNS-resolving hostname in outgoing webhooks (incomplete fix of CVE-2026-53446)
core-osv · Original sourcePublished 19 Aug 2026, 19:22 UTC
Wekan is open source kanban built with Meteor. From 8.36 until 9.74, the outgoing webhook Integration URL validator in models/integrations.js checked only the literal URL.hostname against regular expressions, so DNS names such as 169-254-169-254.nip.io passed that first-line check. The delivery path's fetchSafe guard already blocked the reported IPv4 destination, but its separate IPv4-only resolver and duplicated blocklist created inconsistent all-address-family enforcement and drift risk between input-time and connection-time validation. Version 9.74 makes server/lib/ssrfGuard.js resolve all addresses with `dns.lookup({ all: true })`, validate every result through the shared isIpBlocked logic, pin the connection, and block redirects. This issue is fixed in version 9.74.
osv:CVE-2026-68558
Complete source record
{
"id": "ed4c1dc98fbb54b3ede108e0209f472def057b97c8d32a36b3880664c4cf295c",
"url": "https://osv.dev/vulnerability/CVE-2026-68558",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "Wekan: SSRF filter bypass via DNS-resolving hostname in outgoing webhooks (incomplete fix of CVE-2026-53446)",
"summary": "Wekan is open source kanban built with Meteor. From 8.36 until 9.74, the outgoing webhook Integration URL validator in models/integrations.js checked only the literal URL.hostname against regular expressions, so DNS names such as 169-254-169-254.nip.io passed that first-line check. The delivery path's fetchSafe guard already blocked the reported IPv4 destination, but its separate IPv4-only resolver and duplicated blocklist created inconsistent all-address-family enforcement and drift risk between input-time and connection-time validation. Version 9.74 makes server/lib/ssrfGuard.js resolve all addresses with `dns.lookup({ all: true })`, validate every result through the shared isIpBlocked logic, pin the connection, and block redirects. This issue is fixed in version 9.74.",
"evidence": "osv:CVE-2026-68558",
"products": [],
"severity": "high",
"structured": {
"id": "CVE-2026-68558",
"aliases": [
"CVE-2026-68558",
"GHSA-66m2-4wfr-c45p"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://github.com/wekan/wekan",
"type": "GIT",
"events": [
{
"introduced": "9da7adad9572170c9974a1c9e1c3fc44393a85ae"
},
{
"fixed": "ca9bcfa4eeaf6293737f038381f4a3e91569f851"
},
{
"fixed": "ef845fe4a0adb82af436313310939cd48c0b1347"
}
],
"database_specific": {
"extracted_events": [
{
"range": [
{
"introduced": "8.36"
},
{
"fixed": "9.74"
}
],
"source": "AFFECTED_FIELD",
"strategy": "StringRangeExpression"
},
{
"range": [
{
"fixed": "ef845fe4a0adb82af436313310939cd48c0b1347"
}
],
"source": "REFERENCES_COMMIT"
},
{
"range": [
{
"fixed": "ca9bcfa4eeaf6293737f038381f4a3e91569f851"
}
],
"source": "REFERENCES_TAG",
"original_tag": "v9.74"
}
]
}
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-68558.json"
}
}
],
"modified": "2026-10-28T02:30:24.818935685Z",
"provider": "osv",
"references": [
"https://github.com/wekan/wekan/releases/tag/v9.74",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/68xxx/CVE-2026-68558.json",
"https://github.com/wekan/wekan/security/advisories/GHSA-66m2-4wfr-c45p",
"https://nvd.nist.gov/vuln/detail/CVE-2026-68558",
"https://github.com/wekan/wekan/commit/ef845fe4a0adb82af436313310939cd48c0b1347"
],
"provider_metadata": {
"cwe_ids": [
"CWE-918"
],
"cna_assigner": "GitHub_M",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/68xxx/CVE-2026-68558.json"
}
},
"related_cves": [
{
"value": "CVE-2026-68558",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 491507,
"published_at": "2026-08-19T19:22:18.718+00:00"
}