CVE-2026-33975
SSRF Bypass in Twenty CRM via IPv4-Mapped IPv6 Addresses
Publication date: 2026-05-05
Last updated on: 2026-05-06
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| twentyhq | twenty-server | to 1.18.0 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-918 | The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-33975 is a Server-Side Request Forgery (SSRF) protection bypass vulnerability in the twenty-server package used by the open source CRM Twenty. It affects versions 1.18.0 and earlier.
The issue arises because Node.js's URL parser normalizes IPv4-mapped IPv6 addresses into a compressed hexadecimal form (e.g., ::ffff:a9fe:a9fe), but the SSRF protection utility called isPrivateIp only recognizes these addresses in dotted-decimal notation (e.g., ::ffff:169.254.169.254).
As a result, attackers can bypass SSRF protections by using IPv4-mapped IPv6 addresses in hex form, which are not detected as private or internal IPs. Additionally, a second validation layer based on socket lookup does not trigger for IP literal addresses, further enabling the bypass.
An authenticated user can exploit this vulnerability to access internal IP addresses, including sensitive cloud metadata endpoints, potentially leading to credential exfiltration such as IAM keys.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability allows an authenticated user to bypass SSRF protections and access internal IP addresses, including cloud metadata endpoints, potentially leading to the exfiltration of sensitive credentials such as IAM keys.
This unauthorized access and potential data exfiltration could result in breaches of confidentiality and unauthorized disclosure of sensitive information, which may impact compliance with standards and regulations like GDPR and HIPAA that require protection of personal and sensitive data.
Therefore, if exploited, this vulnerability could lead to non-compliance with such regulations due to failure to adequately protect sensitive data and prevent unauthorized access.
How can this vulnerability impact me? :
This vulnerability allows an authenticated attacker to bypass SSRF protections and reach internal IP addresses that should normally be inaccessible.
By exploiting this, an attacker can access cloud metadata endpoints (e.g., AWS's 169.254.169.254), which can lead to the exfiltration of sensitive credentials such as IAM keys.
Such credential theft can result in full cloud account compromise, allowing attackers to control cloud resources, steal data, or disrupt services.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves SSRF protection bypass using IPv4-mapped IPv6 addresses in hex form that are not recognized by the isPrivateIp utility. Detection involves monitoring for unusual outbound HTTP requests containing IPv4-mapped IPv6 addresses in compressed hex notation (e.g., ::ffff:a9fe:a9fe) targeting internal IP ranges or cloud metadata endpoints such as 169.254.169.254.
You can detect potential exploitation by inspecting logs or network traffic for requests with URLs containing IPv4-mapped IPv6 addresses in hex form.
- Use network monitoring tools (e.g., tcpdump, Wireshark) to filter outbound HTTP requests with patterns matching IPv4-mapped IPv6 hex addresses.
- Example tcpdump command to capture HTTP requests containing IPv6 literals: tcpdump -i <interface> -A 'tcp port 80 and (((ip6[40] == 0x3a) or (ip6[40] == 0x3b)))'
- Search application logs for URLs containing patterns like '::ffff:' followed by hexadecimal segments instead of dotted-decimal notation.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to update the twenty-server package to a version where the isPrivateIp utility correctly handles IPv4-mapped IPv6 addresses in hex notation or normalizes them to dotted-decimal form before validation.
Until an update is applied, consider disabling or restricting outbound HTTP requests from authenticated users to internal IP ranges and cloud metadata endpoints to prevent exploitation.
Review and adjust the OUTBOUND_HTTP_SAFE_MODE_ENABLED setting, as it does not protect against this bypass in default configurations.
Implement network-level controls such as firewall rules to block access to sensitive internal IP addresses and metadata service IPs (e.g., 169.254.169.254).