CVE-2026-123204 in Posta
Summary
by MITRE • 11/05/2026
Posta before v0.18.0 contains a server-side request forgery vulnerability that allows authenticated users with edit rights to make the backend send POST requests to internal destinations by creating webhooks with arbitrary URLs. Attackers can target loopback, private-network or cloud metadata addresses and read delivery status codes and error strings to probe internal hosts and ports.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/05/2026
The identified vulnerability in Posta versions prior to 0.18.0 represents a critical server-side request forgery flaw that exploits the application's webhook functionality. This security defect allows authenticated users who possess edit privileges to manipulate the backend system into initiating HTTP POST requests toward arbitrary, user-specified URLs. By crafting webhooks with maliciously constructed endpoints, an attacker can force the internal server to communicate with destinations of their choosing, effectively turning the legitimate service into a proxy for network reconnaissance and data exfiltration attempts against internal infrastructure.
The technical mechanism behind this exploitation relies on the lack of strict validation or allow-listing mechanisms for webhook destination URLs during creation. When a user defines a new webhook endpoint, the backend processes this input without sufficiently verifying whether the target address resides within an approved domain range or external network boundary. Consequently, attackers can specify internal IP addresses, loopback interfaces such as 127.0.0.1, private network ranges like those defined in RFC 1918, and cloud metadata endpoints typically used for instance configuration retrieval. This absence of input sanitization enables the application to bypass standard perimeter defenses that might otherwise restrict outbound connections from internal services.
The operational impact of this vulnerability is significant as it facilitates detailed internal network probing and potential data theft through blind server-side request forgery techniques. Attackers can leverage the delivery status codes returned by Posta and any error strings generated during failed or successful requests to infer information about internal hosts, open ports, and running services. This side-channel information leakage allows for precise mapping of the internal network topology without direct access to those systems. Furthermore, targeting cloud metadata addresses poses a severe risk as it may lead to the compromise of instance credentials, IAM roles, or other sensitive configuration data stored in these accessible endpoints, potentially escalating privileges across the entire infrastructure.
This vulnerability aligns with Common Weakness Enumeration category CWE-918, which classifies server-side request forgery flaws where an application retrieves a specified resource from a user-supplied URL without proper validation of its legitimacy. Additionally, the exploitation technique corresponds to MITRE ATT&CK tactic T1557, specifically subtechnique T1557.002 for Adversary-in-the-Middle scenarios involving LLMNR/NBT-NS poisoning and SMB relay, although in this context it is more directly related to SSRF-based network discovery and credential harvesting via cloud metadata services. The ability to read response codes and error messages transforms a simple forgery into an active reconnaissance tool capable of mapping internal assets and identifying vulnerable services for further exploitation.
To mitigate this risk, organizations running Posta versions prior to 0.18.0 should immediately upgrade to version 0.18.0 or later where these validation controls have been implemented. In the interim, administrators can enforce network-level restrictions by configuring firewalls or security groups to block outbound POST requests from the application server to internal IP ranges and cloud metadata endpoints unless explicitly required for business operations. Implementing strict URL allow-lists within the application configuration ensures that only pre-approved external domains are accessible via webhooks. Additionally, restricting webhook creation permissions to a minimal set of trusted administrators reduces the attack surface by limiting the number of users capable of triggering this functionality.