SSRF fixed in Foxit PDF Services API URL handling

TL;DR — A High-severity SSRF in Foxit PDF Services API can let a low-privileged attacker force server-side requests to internal or otherwise unreachable endpoints, including cloud metadata services.

What happened

Foxit PDF Services API is a document workflow API used to generate and process PDFs (including workflows that accept user-supplied URLs). CVE-2026-5936 describes a Server-Side Request Forgery (SSRF) weakness where an attacker can supply a crafted URL that causes the service to initiate outbound HTTP requests to attacker-chosen destinations.

The CVE record explicitly calls out typical SSRF pivot outcomes: probing internal network services, reaching otherwise unreachable endpoints (including cloud metadata services), and bypassing network access controls — with potential sensitive information disclosure and follow-on compromise.

Foxit’s security bulletin for the service states the issue was addressed via stricter URL validation/normalization in the outbound-request path.

SSRF remains a high-leverage appsec class because it turns “URL fetch” features into internal network reachability, frequently bridging into metadata credential theft and lateral movement in cloud environments.

Who is impacted

• Deployments using Foxit PDF Services API in the CVE record’s affected range: versions listed as before 2026-04-07.
• Any integration path that allows untrusted users (or untrusted data sources) to influence a URL that the service will fetch server-side (Foxit’s bulletin specifically references “creating PDFs from URLs”).
• Higher-risk environments where the API can reach internal-only services (private VPC endpoints, intranet services, or cloud provider metadata endpoints) from its execution environment.

What to do now

• Follow vendor remediation guidance for CVE-2026-5936.
• Foxit’s bulletin states:

  "No customer action is required."

• Foxit’s bulletin also states:

  "This issue has been resolved by implementing strict validation and normalization of input URLs before making any outbound requests."

• For platform teams using URL-to-PDF (or similar “fetch by URL”) patterns, treat this as a signal to re-check your own layered controls (input allowlists/denylists, outbound egress policies, and request logging) because SSRF is frequently chained even after initial fixes.
• If you suspect abuse, review request logs for anomalous URL fetch patterns (unexpected schemes/hosts, private IP ranges, or metadata hostnames) and rotate any credentials that could have been exposed via internal service access.