Unauthenticated server-side request forgery in Examplecorp Edge Gateway document rendering
An unauthenticated request to the document rendering endpoint causes the gateway to fetch a URL of the caller choosing from inside the trust boundary. Versions 7.0.0 through 7.4.1 are affected. A patch is available in 7.4.2 and the flaw is on the CISA KEV catalogue.
Key facts
- CVSS v4
- 9.3
- EPSS
- 0.72
- CISA KEV
- 30 July 2026
- Patch
- 27 July 2026
Source: NVD
97th percentile · FIRST
Source: CISA
Patched in 7.4.2, released 2026-07-27
- Affected
- Examplecorp Edge Gateway 7.0.0 through 7.4.1
- Weakness
- CWE-918: Server-Side Request Forgery
- Vector
CVSS:4.0/ AV:N/ AC:L/ AT:N/ PR:N/ UI:N/ VC:H/ VI:L/ VA:N/ SC:H/ SI:N/ SA:N
What is CVE-2026-99001?
Examplecorp Edge Gateway exposes a document rendering service that accepts a job specification and resolves the assets that job references. The endpoint that accepts the specification does not require authentication in the default configuration, and the asset resolver does not constrain the destination of the fetches it performs. The result is a server-side request forgery reachable by anyone who can reach the gateway.
The gateway is deployed at the network edge by design, which is what makes this more serious than the same flaw in an internal service: the component with the unrestricted outbound fetch is the component with the most reachable inbound surface.
How does the vulnerability work?
The asset resolver validates the submitted URL against a deny-list of loopback and private address literals before scheduling the fetch. Two properties of that check defeat it. It runs against the hostname as submitted rather than against the address the resolver returns, so a name under attacker control that resolves to an internal address passes. And the fetch client follows redirects without re-validating, so an allow-listed host that answers with a 302 hands over the destination.
This is the ordinary shape of the class rather than anything novel, which is worth stating plainly: the interesting part of this advisory is where the component sits, not what the bug is.
Is it being exploited in the wild?
The identifier is on the CISA Known Exploited Vulnerabilities catalogue as of 2026-07-30, which is the load-bearing fact for prioritisation. EPSS puts it at 0.72, in the 97th percentile. Treat both figures as inputs with dates attached rather than as a standing property of the vulnerability: EPSS moves, sometimes sharply, in the weeks after a public proof of concept appears.
How do I detect exploitation?
The reliable signal is outbound, not inbound. Requests to the rendering endpoint look ordinary and there is no payload signature worth alerting on. What is anomalous is the gateway process opening a connection to an address it has no business reaching, so the detection below is written against egress telemetry and is deliberately behavioural.
How do I fix it?
- Upgrade to 7.4.2 or later. This is the only complete fix.
- If you cannot patch immediately, require authentication on the rendering endpoint at the reverse proxy. This removes the unauthenticated reachability, which is the property that put the identifier on KEV.
- Apply an egress policy to the gateway workload that permits only the destinations it genuinely needs. This is the control that limits impact independently of the patch, and it is worth keeping afterwards.
- Where the gateway runs on a cloud instance, require signed-token metadata access so that reaching the metadata endpoint is not sufficient to obtain a credential.
- Review outbound connection logs for the affected window before assuming you were not reached.
How exploitable is it really?
See the analyst assessment above. In short: reliable, unauthenticated, and bounded almost entirely by your egress policy rather than by anything the attacker controls.
Practise this safely
The blind SSRF lab reproduces the same class in a sandboxed environment with a simulated metadata service, so the technique is practised against a target that exists only inside the lab network and reaches nothing real.
Copy this, tune it, keep it
Written against the class rather than the identifier, so it stays useful after you patch.
title: Edge gateway process connecting to internal or link-local address
id: 5c0e0f2a-4a5d-4a0e-9d6e-3f1a2b7c8d90
status: experimental
description: >
Detects the document rendering worker opening an outbound connection to a
link-local or RFC 1918 destination. Written for the CVE-2026-99001 class:
the inbound request is unremarkable, the outbound connection is not.
references:
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog
author: Cyber VK detection engineering
date: 2026/07/28
logsource:
category: network_connection
detection:
selection_process:
Image|endswith:
- '/edge-gateway-render'
- '\edge-gateway-render.exe'
selection_destination:
DestinationIp|cidr:
- '169.254.0.0/16'
- '10.0.0.0/8'
- '172.16.0.0/12'
- '192.168.0.0/16'
- '127.0.0.0/8'
filter_known_internal_assets:
# TUNE THIS FIRST. Add every internal host the renderer legitimately
# fetches from, with a comment saying why, before enabling the rule.
DestinationIp:
- '10.20.0.0/24'
condition: selection_process and selection_destination and not filter_known_internal_assets
falsepositives:
- Internal asset hosts that have not been added to the filter
- Health checks and service discovery traffic from the same image
level: highWhat is in scope
| Product | Affected | Fixed in | Platform |
|---|---|---|---|
| Examplecorp Edge Gateway | 7.0.0 to 7.4.1 | 7.4.2 | Linux, self-hosted |
| Examplecorp Edge Gateway | 7.2.0 to 7.4.1 | 7.4.2 | Container image |
| Examplecorp Edge Gateway Cloud | Not affected | n/a | Vendor hosted |
How exploitable is it really
The raw score reads as a full-impact critical and the real risk profile is narrower than that, but not by much. Exploitation is trivially reliable and needs no authentication, which is what puts it on KEV. What decides the outcome for any given deployment is what the gateway can reach outbound: an instance behind a restrictive egress policy gives an attacker a scanner and very little else, while a default deployment on a cloud instance with credential-bearing metadata reachable gives them a credential. Patch on the normal emergency path, and treat the egress question as the thing that tells you how bad the last week was.
Reproduce this in a sandbox
Blind SSRF to cloud metadata
Prove that a server-side request forgery with no visible response can still reach an internal service, and write the finding so a triager cannot close it as informational.
Where these numbers come from
- NVD, the vulnerability record and CVSS dataRetrieved 4 August 2026
- CISA Known Exploited Vulnerabilities catalogueRetrieved 4 August 2026
- FIRST, EPSS scoring model and daily scoresRetrieved 4 August 2026
Terms used on this page
Cyber VK Security Curriculum
Pre-publication content owner
Internal ownership label for the web-security curriculum.
Technically reviewed by Cyber VK Defensive Research
Published Updated
[ Related ]
- LabBlind SSRF to cloud metadataProve that a server-side request forgery with no visible response can still reach an internal service, and write the finding so a triager cannot close it as informational.
- GlossaryServer-Side Request ForgeryServer-side request forgery is a vulnerability in which an attacker causes a server to make an HTTP request to a destination the attacker chooses, using the server as the origin of that request instead of their own machine.
- ArticleWhy your SSRF report gets closed as informationalMost blind SSRF reports are closed without a payout, and usually for the same three reasons. Here is what a triager is actually looking for, and how to supply it without touching anything you should not.
- GlossaryInsecure Direct Object ReferenceAn insecure direct object reference is an access control failure in which an application uses a user-supplied identifier to select a record and does not check that the requesting user is allowed to see that particular record.
- CTF roomLedger DriftA small internal accounting application with a self-service export feature and an authorisation model that was written before the tenanting was.
- GlossaryCross-Site Request ForgeryCross-site request forgery is a vulnerability in which a site an attacker controls causes a victim browser to send a state-changing request to a different site where the victim is already authenticated, using credentials the browser attaches automatically.