CVE-2026-34576
Received Received - Intake
SSRF in Postiz Upload Endpoint Allows Internal Data Access

Publication date: 2026-04-02

Last updated on: 2026-04-07

Assigner: GitHub, Inc.

Description
Postiz is an AI social media scheduling tool. Prior to version 2.21.3, the POST /public/v1/upload-from-url endpoint accepts a user-supplied URL and fetches it server-side using axios.get() with no SSRF protections. The only validation is a file extension check (.png, .jpg, etc.) which is trivially bypassed by appending an image extension to any URL path. An authenticated API user can fetch internal network resources, cloud instance metadata, and other internal services, with the response data uploaded to storage and returned to the attacker. This issue has been patched in version 2.21.3.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-04-02
Last Modified
2026-04-07
Generated
2026-05-07
AI Q&A
2026-04-02
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
gitroom postiz to 2.21.3 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
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-34576 is a Server-Side Request Forgery (SSRF) vulnerability in the Postiz social media scheduling tool, specifically in the POST /public/v1/upload-from-url endpoint prior to version 2.21.3.

This endpoint accepts a user-supplied URL and fetches it server-side using axios.get() without proper SSRF protections. The only validation is a check on the file extension (e.g., .png, .jpg), which is easily bypassed by appending an image extension to any URL path.

Because of missing hostname, IP, and scheme validation, an authenticated API user can trick the server into fetching internal network resources, cloud instance metadata, and other internal services. The fetched data is then uploaded to storage and a URL to this data is returned to the attacker.

This vulnerability allows attackers to bypass security boundaries and access sensitive internal or cloud metadata endpoints.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

CVE-2026-34576 enables authenticated API users to perform Server-Side Request Forgery (SSRF) attacks that can lead to the theft of cloud credentials and exposure of internal network services and data.

This exposure of sensitive data, including cloud metadata and internal services, can result in unauthorized access to confidential information, which may violate data protection regulations such as GDPR and HIPAA that require safeguarding personal and sensitive data.

The vulnerability's high confidentiality impact and potential for data exfiltration increase the risk of non-compliance with these standards, as it undermines the security controls necessary to protect sensitive data from unauthorized disclosure.


How can this vulnerability impact me? :

This vulnerability can have serious impacts including:

  • Theft of cloud credentials by accessing cloud metadata endpoints (such as AWS, GCP, Azure), potentially leading to full cloud infrastructure compromise.
  • Enumeration and scanning of internal network services and hosts that are not accessible externally.
  • Access to sensitive internal services like databases, admin panels, and caches.
  • Exfiltration of data since all fetched responses are uploaded to cloud storage and a download URL is returned to the attacker.

Overall, the vulnerability allows an authenticated user to escape the application’s security boundary and gain unauthorized access to internal and cloud resources.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring for suspicious POST requests to the `/public/v1/upload-from-url` endpoint with URLs that include internal IP addresses, cloud metadata IPs (e.g., 169.254.169.254), or other internal network resources appended with image file extensions like .png or .jpg.

Example detection commands include inspecting web server logs or API gateway logs for such requests.

  • Using grep to find suspicious URLs in logs: grep -E 'POST /public/v1/upload-from-url' /var/log/nginx/access.log | grep -E '169\.254\.169\.254|127\.0\.0\.1|10\.|172\.|192\.168\.'
  • Using curl or HTTP client to test if the endpoint fetches internal URLs: curl -X POST -d '{"url":"http://169.254.169.254/latest/meta-data/iam/security-credentials/role.png"}' https://your-postiz-instance/public/v1/upload-from-url

Additionally, monitoring for unexpected outbound requests from the server to internal IP ranges or cloud metadata IPs can help detect exploitation attempts.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include:

  • Upgrade the postiz-app to version 2.21.3 or later, where this vulnerability has been patched.
  • Apply SSRF protections such as the existing `IsSafeWebhookUrl` validator to the `UploadDto` URL field to block private IP ranges and unsafe URLs.
  • Enforce scheme validation to allow only safe URL schemes like `http://` and `https://`.
  • Implement DNS resolution validation to prevent DNS rebinding attacks by resolving hostnames before fetching and verifying IPs against blocklists.
  • Set timeouts and response size limits on the server-side HTTP client (`axios.get()`) to prevent resource exhaustion.

Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart