Which versions of Twenty CRM are affected by CVE-2026-33975?

Twenty CRM versions 1.18.0 and earlier contain a server-side request forgery (SSRF) vulnerability that allows authenticated users to bypass network security controls and access cloud metadata…

How to fix or mitigate CVE-2026-33975?

Within 24 hours: inventory all Twenty CRM deployments and document current version numbers; verify cloud metadata endpoint access logs (169.254.169.254) for suspicious requests. Within 7 days: upgrade to Twenty CRM version 1.19.0 or later when available, or implement network-level egress filtering to block access to 169.254.169.254 and cloud provider metadata ranges if running version 1.18.0 or earlier. Within 30 days: audit all authenticated CRM user accounts for suspicious activity; review IAM credential access logs and rotate any credentials that may have been exposed.

Twenty CRM CVE-2026-33975

Q: What is the CVSS score of CVE-2026-33975?

CVE-2026-33975 has a CVSS 4.0 base score of 8.3 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.0%.

EUVD-2026-27452 HIGH

Server-Side Request Forgery (SSRF) (CWE-918)

2026-05-05 GitHub_M

SSRF Node.js Twenty Twentyhq

8.3

CVSS 4.0 · Vendor: GitHub_M

Severity by source

Vendor (GitHub_M) PRIMARY

8.3 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Primary rating from Vendor (GitHub_M) · only source for this CVE.

CVSS VectorVendor: GitHub_M

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Lifecycle Timeline

Analysis Generated

May 05, 2026 - 22:01 vuln.today

CVSS changed

May 05, 2026 - 20:22 NVD

8.3 (HIGH)

DescriptionCVE.org

Twenty is an open source CRM built with NestJS (Node.js). In versions 1.18.0 and earlier, the SSRF protection in twenty-server's SecureHttpClientService can be bypassed using IPv4-mapped IPv6 addresses in URL IP literals. Node.js's URL parser normalizes IPv4-mapped IPv6 addresses to compressed hex form (e.g., ::ffff:169.254.169.254 becomes ::ffff:a9fe:a9fe), but the isPrivateIp utility only recognizes the dotted-decimal notation. As a result, the hex form passes the SSRF check unchecked. Additionally, the socket lookup validation event does not fire for IP literal addresses, bypassing the second validation layer. An authenticated user can reach any internal IP, including cloud metadata endpoints, to exfiltrate credentials such as IAM keys.

AnalysisAI

Server-side request forgery (SSRF) in Twenty CRM allows authenticated users to bypass IP filtering protections and access internal network resources, including cloud metadata endpoints containing IAM credentials. The vulnerability affects versions 1.18.0 and earlier through exploitation of IPv4-mapped IPv6 address normalization inconsistencies in Node.js URL parsing versus the isPrivateIp validation utility. Attackers with low-privilege authenticated access can exfiltrate sensitive credentials from cloud provider metadata services (169.254.169.254). No public exploit code or active exploitation (CISA KEV) confirmed at time of analysis, though the technical details in the GitHub security advisory provide a clear exploitation path.

Technical ContextAI

The vulnerability exists in Twenty CRM's SecureHttpClientService, a component designed to prevent SSRF attacks by validating that user-supplied URLs do not target private IP ranges. The issue stems from an impedance mismatch between Node.js's native URL parser and the custom isPrivateIp validation function. When an attacker provides an IPv4-mapped IPv6 address in URL literal format (e.g., http://[::ffff:169.254.169.254]/), Node.js normalizes this to compressed hexadecimal notation (::ffff:a9fe:a9fe) before validation. The isPrivateIp utility only recognizes IPv4-mapped addresses in dotted-decimal notation (::ffff:169.254.169.254), allowing the hex-encoded private IP to pass validation. Furthermore, Node.js's socket lookup event-intended as a second validation layer-does not fire for IP literal addresses, completely bypassing runtime IP checks. This dual failure enables authenticated users to craft requests to RFC 1918 private networks, link-local addresses (169.254.0.0/16 used by AWS/Azure/GCP metadata services), and localhost. CWE-918 (Server-Side Request Forgery) classification is accurate, as the application makes attacker-controlled HTTP requests without sufficient destination validation.

RemediationAI

Upgrade to Twenty CRM version >1.18.0 once vendor releases patched version addressing GHSA-vrcj-hv2q-c58m (specific fixed version not confirmed in available data-consult https://github.com/twentyhq/twenty/security/advisories/GHSA-vrcj-hv2q-c58m for release announcement). Until patched version is deployed, implement network-layer compensating controls with the following trade-offs: (1) Configure egress firewall rules to block twenty-server processes from accessing 169.254.169.254/32, RFC 1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), and localhost (127.0.0.0/8, ::1/128)-this prevents metadata service access but may break legitimate integrations requiring internal network communication; (2) If running in AWS, enforce IMDSv2 (requiring PUT request with token) via instance metadata options, which mitigates simple GET-based SSRF but does not eliminate vulnerability if attacker controls HTTP method; (3) Disable or restrict SecureHttpClientService functionality if webhook/external HTTP features are not business-critical-this eliminates attack surface but reduces CRM integration capabilities; (4) Implement application-layer allowlist of permitted destination domains rather than IP-based blocklisting-requires operational overhead to maintain but provides defense-in-depth. Review application logs for requests to IPv6 literal addresses (pattern: http://\[.*\]) as potential exploitation indicators.