Unauthenticated External Connections via Run Configurations in IntelliJ IDEA

In JetBrains IntelliJ IDEA before 2026.3, 2026.2.4 unauthenticated connection to an arbitrary host via run configurations was possible

Apache James: SSRF filter bypass in the JMAP PushSubscription web-push client

In Apache James server prior version 3.9.1 improper validation in JMAP webPush SSRF validation did lead to the possibility to reach internal addresses. Users are recommended to upgrade to version 3.9.1 which fixes this issue.

MikroDash before 0.8.79 SSRF via Personal Notification Channels

MikroDash before 0.8.79 contains a server-side request forgery vulnerability that allows any signed-in user, including the viewer role, to target internal addresses through notification channels. Attackers can set webhook or mail destinations to loopback, LAN or link-local addresses and call POST /api/notify-channels/{id}/test to probe the internal network.

Mediary Scout before 2026.11.05 SSRF via PanSou Search Source Setting

Mediary Scout before 2026.11.05 contains a server-side request forgery vulnerability that allows any authenticated user, including non-owner accounts, to set an arbitrary PanSou base URL via savePanSouBaseUrlAction without role checks. Attackers can trigger probePanSou() to send server-side POST requests to internal hosts and use distinct error responses as an oracle for internal host and port discovery.

pyLoad WindowsPhoneNotify addon: non-admin SETTINGS user triggers SSRF via unguarded http.client notification host

pyLoad is a free and open-source download manager written in Python. Prior to 0.5.0b3.dev102, an authenticated non-admin user with the SETTINGS permission can configure WindowsPhoneNotify through /json/save_config by setting pushurl, pushid, and enabled. WindowsPhoneNotify.send in src/pyload/plugins/addons/WindowsPhoneNotify.py then uses http.client.HTTPConnection without pyLoad's pycurl destination validation. When a download completes, the global notification event causes a blind POST from the pyLoad server to the attacker-selected internal host, port, and path. The response is not returned, but the request can probe internal services, reach cloud metadata endpoints, or trigger state-changing internal HTTP endpoints. This issue is fixed in version 0.5.0b3.dev102.

SuiteCRM: Authenticated SSRF in CalendarAccount testConnection Allows Internal Network Access and Response Disclosure

SuiteCRM is an open-source, enterprise-ready Customer Relationship Management (CRM) software application. Prior to 7.15.2 and 8.10.2, the CalendarAccount testConnection action passes an authenticated caller's server_url directly to curl without host, address, or scheme validation. The affected flow begins at CalendarAccount::action_testConnection and uses server_url, CalDAVProvider::makeCalDAVRequest(), and PROPFIND to carry attacker-controlled data or authorization state into the security-sensitive operation. The server sends a PROPFIND request from its network context and returns non-success response bodies, enabling internal-service access, partial response disclosure, service enumeration, and possible cloud metadata access. This issue is fixed in versions 7.15.2 and 8.10.2.

SuiteCRM: Non-admin user creates SchedulersJob: SSRF via cron

SuiteCRM is an open-source, enterprise-ready Customer Relationship Management (CRM) software application. Prior to 7.15.2 and 8.10.2, the V8 module API lacks module-level authorization and permits a low-privileged user to create SchedulersJobs records with attacker-controlled target values. The affected flow begins at /Api/V8/module and uses SchedulersJobs, target, cron.php, and url:: to carry attacker-controlled data or authorization state into the security-sensitive operation. Cron.php later executes the queued job with system privileges, and the url:: target makes server-side requests to internal or external hosts, can follow redirects, can persist as a recurring job, and may expose internal services. This issue is fixed in versions 7.15.2 and 8.10.2.

SuiteCRM: Mass Assignment in V8 API Allows Modification of Sensitive User Fields (user_hash, external_auth_only)

SuiteCRM is an open-source, enterprise-ready Customer Relationship Management (CRM) software application. Prior to 7.15.2 and 8.10.2, the V8 write path checks that a field exists but does not enforce api-visible or sensitive metadata that hides the same field on reads. The affected flow begins at PATCH /Api/V8/module and uses user_hash, external_auth_only, api-visible: false, and sensitive: true to carry attacker-controlled data or authorization state into the security-sensitive operation. An authenticated user can mass-assign internal authentication fields, modify password hashes or external-authentication flags, and persist unauthorized account access. This issue is fixed in versions 7.15.2 and 8.10.2.

SuiteCRM: isSelfRequest() bypass via substring match allows SSRF to internal services

SuiteCRM is an open-source, enterprise-ready Customer Relationship Management (CRM) software application. Prior to 7.15.2 and 8.10.2, the SSRF protection added in 7.15.1 uses a substring comparison in isSelfRequest() rather than hostname equality. The affected flow begins at validate_external_host() and uses isSelfRequest(), and stripos() to carry attacker-controlled data or authorization state into the security-sensitive operation. An authenticated attacker can place the server hostname in a URL path to bypass IP validation and direct server-side requests to internal services. This issue is fixed in versions 7.15.2 and 8.10.2.

Processing instruction target and content emitted unescaped in Saxy encoder allows XML injection

Saxy's XML encoder writes the target and the content of a processing instruction into the output document verbatim, without validation or escaping. The encoder builds the construct by concatenating both fields between <? and ?>, so neither field is checked against the constraints the XML specification places on it. Because ?> terminates a processing instruction, a target or content value containing that sequence closes the construct at a position the attacker chooses. Everything the attacker writes after it is emitted as ordinary markup at document level, which allows arbitrary elements, attributes, and further processing instructions to be injected into the serialized document. Appending a matching <? keeps the encoder's own terminator well-formed, so the result still parses and the injection is silent rather than a visible corruption. The target is additionally unconstrained by the XML Name production, which permits injection before the remainder of the processing instruction. The result is XML injection into a serialized document: the tree the application asks Saxy to encode and the tree a downstream parser reads back are no longer the same. Character data, attribute values, and comments are all escaped by the encoder, so processing instructions are the one construct that passes user bytes through untouched. Since Saxy.XML.processing_instruction/2 is a documented public builder, an application inherits the flaw without misusing the API. The consequences depend on what consumes the XML: forged records in a feed or export read by another system, injected stylesheet or rendering directives, or active content where the output is served to a browser as XML or SVG. This issue affects saxy: from 0.7.0 before 1.7.0.

XML injection in Saxy via unescaped CDATA section terminator

XML injection in the Saxy XML encoder. Saxy.Encoder.cdata/1 serializes a {:cdata, characters} node by wrapping the supplied characters between <![CDATA[ and ]]> and passing the payload through byte for byte. The encoder's character-data and attribute-value paths escape the XML metacharacters <, >, &, ", and ', but the CDATA path applies no neutralization at all. XML provides no character escaping mechanism inside a CDATA section, so the only correct way to represent a ]]> substring is to split the section and rejoin it as ]]]]><![CDATA[>. Saxy neither performs that split nor rejects the substring. An application that renders untrusted text as CDATA, by building the node with Saxy.XML.cdata/1 and serializing it with Saxy.encode!/2 or Saxy.encode_to_iodata!/2, therefore lets an attacker terminate the section at a position of their choosing. Everything supplied after the ]]> is emitted outside any CDATA context and is parsed as markup, so a single attacker-controlled text field becomes attacker-controlled document structure: arbitrary sibling elements and attributes that the application never built. Downstream consumers of the serialized document accept the injected markup as genuine. Services that generate SOAP envelopes, RSS or Atom feeds, sitemaps, SVG, or XML exports from user-supplied content can have trusted fields forged or overridden. Applications that never place untrusted text in a CDATA node are not affected. This issue affects saxy: from 0.7.0 before 1.7.0.

XML comment injection in Saxy encoder via unescaped double hyphen

XML injection in the encoder of Saxy. Saxy.Encoder does not neutralize the -- sequence in XML comment content: escape_comment/2 returns the comment binary unchanged in every clause and only appends a space when the comment ends in a single -, so neither an interior -- nor a full --> is escaped or rejected before the encoder wraps the content in the <!-- and --> delimiters. When an application serializes attacker-controlled text as a comment, through Saxy.XML.comment/1 or a raw {:comment, text} simple form child, the attacker can close the comment early with --> and inject arbitrary sibling markup into the serialized document. A downstream parser then sees elements, attributes, and text that the application never built. Where the document is rendered as HTML or SVG, the injected markup executes as stored cross-site scripting; where it is consumed by another XML processor, the attacker can forge data that the producing application never emitted. Documents that Saxy only parses are not a vector. This issue affects saxy: from 0.7.0 before 1.7.0.

Server-side request forgery in the Active Directory credential validation in Devolutions Server 2026.3.12.0 and earlier allows an authenticated low-privileged user to capture the NetNTLMv2 hash of the DVLS service account via an attacker-controlled domain name in the request.

NocoBase: SSRF in customRequests:send via runtime options.url override

NocoBase is an AI-powered no-code/low-code platform for building business applications and enterprise solutions. Versions 2.1.0 through 2.1.14 contain a server-side request forgery vulnerability in the customRequests:send endpoint. A low-privileged authenticated user can override the stored request URL at runtime using options.url, causing the NocoBase server to send requests to attacker-controlled or internal destinations. Exploitation could expose internal services, Docker host gateways, or cloud metadata endpoints and allow the server to be used as a trusted network proxy. This issue has been fixed in version 2.1.15.

Apache OFBiz: Server-side request forgery in SurveyWrapper

Server-Side Request Forgery in SurveyWrapper in Apache OFBiz 24.09 before 24.09.08 on all platforms allows an authenticated back-office user holding catalog permission to cause the server to fetch and render attacker-controlled URLs — including internal network and cloud-metadata endpoints and local files via file:// — by setting an arbitrary URL as a product-store survey's template location, causing SurveyWrapper.getTemplate to call URL.openStream() on the resolved location and compile the fetched content as a FreeMarker template with no scheme or host validation, unlike the sibling widget location-loaders (ScreenFactory, FormFactory, GridFactory, MenuFactory, TreeFactory, ThemeFactory) which validate the resolved location before loading it. The fetched content is rendered into the HTTP response of any shopper who subsequently loads the affected product-store survey, making the disclosure non-blind. Users are recommended to upgrade to version 24.09.08, which fixes this issue.

Multiple Vulnerabilities in IBM API Connect

IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote authenticated attacker to obtain sensitive information from internal network resources due to server-side request forgery. Destination checks on outbound requests can be bypassed, which could allow the server to reach internal systems that should be blocked.

Multiple Vulnerabilities in IBM API Connect

IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote authenticated attacker to obtain sensitive information due to server-side request forgery.

Multiple Vulnerabilities in IBM API Connect

IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote authenticated attacker to obtain sensitive information due to server-side request forgery.

Multiple Vulnerabilities in IBM API Connect

IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote authenticated attacker to obtain sensitive information due to improper validation of user-supplied URLs.

Multiple Vulnerabilities in IBM API Connect

IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote authenticated attacker to obtain sensitive information due to improper input validation. Locations supplied when service definitions are imported are not sufficiently validated, which could allow the server to retrieve content it should not access.