CVE-2026-33655: New API: SSRF Protection Bypass via Unresolved Hostname in Notification URLs

Published Jul 7, 2026
·
Updated

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/systemsetting/fetchsetting.go, common/ssrfprotection.go, service/webhook.go, and service/usernotify.go.

Other sources

New API is a large language mode (LLM) gateway and artificial intelligence (AI) asset management system. Prior to 0.12.0-alpha.1, 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, allowing authenticated users to configure Webhook, Bark, or Gotify notification URLs that point at an internal or metadata IP address. This issue is fixed in version 0.12.0-alpha.1.

MITRE

Affected Software

2 affected componentsFixes available
go/github.com/QuantumNous/new-api<0.12.0-alpha.1
0.12.0-alpha.1
Newapi New Api<0.12.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade go/github.com/QuantumNous/new-api to a version that resolves this vulnerability.

    Fixed in 0.12.0-alpha.1
  2. Upgrade

    Upgrade to a fixed release to a version that resolves this vulnerability.

    Fixed in 0.12.0-alpha.1Patch 20399d3c8fcb4e3649d53163eb11940fd6763743
  3. Configuration

    Explicitly enable ApplyIPFilterForDomain so hostname notification URL destinations are resolved and the resolved IPs are checked against the configured IP filtering rules.

    SSRF protection (URL validation) / fetch setting ApplyIPFilterForDomain = true
  4. Configuration

    Restrict notification URL domains with an allowlist (Webhook, Bark, Gotify) to prevent pointing hostnames at internal or metadata IP addresses.

    Notification URL configuration notification URL domain allowlist (Webhook/Bark/Gotify) = restrict to allowed domains only
  5. Configuration

    Disable user-configurable notification URLs where practical, so authenticated users cannot set Webhook/Bark/Gotify notification URLs.

    Notification URL configuration user-configurable notification URLs = disabled where practical
  6. Compensating control

    Enforce outbound network filtering at the host or network layer to block connections from the deployment network to internal/metadata HTTP services.

Event History

Jul 7, 2026
Advisory Published
via GitHub·01:01 PM
Data Sourced
via GitHub·01:01 PM
DescriptionSeverityWeaknessAffected Software
Jul 9, 2026
CVE Published
via MITRE·10:28 PM
Data Sourced
via MITRE·10:28 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·11:17 PM
RemedyDescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

What is the severity of CVE-2026-33655?

CVE-2026-33655 has a high severity rating of 7.7.

2

What type of vulnerability is CVE-2026-33655?

CVE-2026-33655 is a Server-Side Request Forgery (SSRF) vulnerability.

3

How do I fix CVE-2026-33655?

To fix CVE-2026-33655, enable the IP filtering configuration by setting 'ApplyIPFilterForDomain' to true.

4

Who is affected by CVE-2026-33655?

Authenticated users of the affected software can exploit CVE-2026-33655 if IP filtering is not applied.

5

What impact does CVE-2026-33655 have?

CVE-2026-33655 allows authenticated users to bypass URL validation, potentially leading to unauthorized network access.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203