Skip to main content

CVE-2026-33655

HIGH
Server-Side Request Forgery (SSRF) (CWE-918)
2026-07-07 https://github.com/QuantumNous/new-api GHSA-6qcr-qxgr-m7fv
7.7
CVSS 3.1 · Vendor: https://github.com/QuantumNous/new-api
Share

Severity by source

Vendor (https://github.com/QuantumNous/new-api) PRIMARY
7.7 HIGH
AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

Primary rating from Vendor (https://github.com/QuantumNous/new-api) · only source for this CVE.

CVSS VectorVendor: https://github.com/QuantumNous/new-api

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N
Attack Vector
Network
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Changed
Confidentiality
High
Integrity
None
Availability
None

Lifecycle Timeline

2
Analysis Generated
Jul 07, 2026 - 13:34 vuln.today
CVE Published
Jul 07, 2026 - 13:01 github-advisory
HIGH 7.7

DescriptionCVE.org

Summary

The default SSRF protection configuration did not apply IP filtering to hostnames. With ApplyIPFilterForDomain disabled by default, URL validation checked domain allow/block rules but did not resolve a hostname and validate the resolved IP address. Authenticated users could configure notification URLs for Webhook, Bark, or Gotify notifications and point a hostname at an internal or metadata IP address.

Impact

A regular authenticated user could cause the server to send notification requests to internal HTTP services reachable from the deployment network. Depending on the target environment, this could expose sensitive internal data through timing, errors, or response-dependent behavior. The issue is rated High.

Affected versions

Versions before v0.12.0-alpha.1 are affected. The previous affected range of <= v0.11.4-alpha.4 was too narrow because the unsafe default remained present until the v0.12.0-alpha.1 fix.

Patches

This issue is fixed in v0.12.0-alpha.1. The default fetch setting now sets ApplyIPFilterForDomain: true, causing hostname destinations to be resolved and checked against the configured IP filtering rules during URL validation.

This patch addresses the unresolved-hostname bypass for the affected notification URL paths. It does not mark the separate DNS rebinding advisory as fixed, because connection-time IP enforcement is tracked separately.

Workarounds

If upgrading immediately is not possible, explicitly enable ApplyIPFilterForDomain, restrict notification URL domains with an allowlist, disable user-configurable notification URLs where practical, and enforce outbound network filtering at the host or network layer.

Resources

  • Fixed by commit 20399d3c8fcb4e3649d53163eb11940fd6763743.
  • Relevant code paths: setting/system_setting/fetch_setting.go, common/ssrf_protection.go, service/webhook.go, and service/user_notify.go.

AnalysisAI

Server-side request forgery in QuantumNous New API (an open-source LLM API gateway/proxy) lets any authenticated low-privilege user coerce the server into making HTTP requests to internal or cloud-metadata IP addresses via notification URL configuration. Because the default SSRF protection (ApplyIPFilterForDomain disabled) validated only the literal hostname against domain allow/block lists and never resolved and re-checked the destination IP, a user could set Webhook, Bark, or Gotify notification URLs whose hostname points at internal services. …

Unlock full vulnerability intelligence

  • Risk assessment & exploitation conditions
  • Attack chain visualization
  • Remediation with exact patch versions
  • Threat intelligence from 22 sources
  • Personal watchlist & email alerts

Free forever · No credit card required

Recommended ActionAI

Within 24 hours: Audit all QuantumNous API Gateway deployments and implement network segmentation limiting outbound connectivity. …

Sign in for detailed remediation steps and compensating controls.

Threat intelligence, references, and detailed analysis are available after sign-in.

Share

CVE-2026-33655 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy