7.1 CVE-2025-22501

This attack is a form of Cross-Site Scripting (XSS) where malicious scripts are embedded in elements that are not expected to host scripts such as image tags (<img>), comments in XML documents (< !-CDATA->), etc. These tags may not be subject to the same input validation, output validation, and other content filtering and checking routines, so this can create an opportunity for an adversary to tunnel through the application's elements and launch a XSS attack through other elements. As with all remote attacks, it is important to differentiate the ability to launch an attack (such as probing an internal network for unpatched servers) and the ability of the remote adversary to collect and interpret the output of said attack. [Survey the application for user-controllable inputs] Using a browser or an automated tool, an adversary records all entry points for inputs that happen to be reflected in a client-side non-script element. These non-script elements can be located in the HTML content (head, body, comments), in an HTML tag, XML, CSS, etc. [Probe identified potential entry points for XSS vulnerability] The adversary uses the entry points gathered in the "Explore" phase as a target list and injects various common script payloads to determine if an entry point actually represents a vulnerability and to characterize the extent to which the vulnerability can be exploited. [Create malicious XSS content] Once the adversary has determined which entry points are vulnerable to XSS, they will interact with the web application to store the malicious content. Because of the nature of this attack, it is mostly carried out through stored XSS, although it is possible to perform this attack using reflected XSS. The adversary can have many goals, from stealing session IDs, cookies, credentials, and page content from a victim. [Get victim to view stored content] In order for the attack to be successful, the victim needs to view the stored malicious content on the webpage.

In this pattern the adversary is able to load and execute arbitrary code remotely available from the application. This is usually accomplished through an insecurely configured PHP runtime environment and an improperly sanitized "include" or "require" call, which the user can then control to point to any web-accessible file. This allows adversaries to hijack the targeted application and force it to execute their own instructions. [Survey application] Using a browser or an automated tool, an adversary follows all public links on a web site. They record all the links they find. [Attempt variations on input parameters] The attack variants make use of a remotely available PHP script that generates a uniquely identifiable output when executed on the target application server. Possibly using an automated tool, an adversary requests variations on the inputs they surveyed before. They send parameters that include variations of payloads which include a reference to the remote PHP script. They record all the responses from the server that include the output of the execution of remote PHP script. [Run arbitrary server-side code] As the adversary succeeds in exploiting the vulnerability, they are able to execute server-side code within the application. The malicious code has virtual access to the same resources as the targeted application. Note that the adversary might include shell code in their script and execute commands on the server under the same privileges as the PHP runtime is running with.

An adversary embeds malicious script code in the parameters of an HTTP query string and convinces a victim to submit the HTTP request that contains the query string to a vulnerable web application. The web application then procedes to use the values parameters without properly validation them first and generates the HTML code that will be executed by the victim's browser. [Survey the application for public links] Using a browser or an automated tool, an adversary follows all public links on a web site. They record all the links they find. [Probe public links for XSS vulnerability] The adversary uses the public links gathered in the "Explore" phase as a target list and requests variations on the URLs they spidered before. They send parameters that include variations of payloads. They record all the responses from the server that include unmodified versions of their script. [Craft malicious XSS URL] Once the adversary has determined which parameters are vulnerable to XSS, they will craft a malicious URL containing the XSS exploit. The adversary can have many goals, from stealing session IDs, cookies, credentials, and page content from the victim. [Get victim to click URL] In order for the attack to be successful, the victim needs to access the malicious URL.

An adversary exploits web applications that generate web content, such as links in a HTML page, based on unvalidated or improperly validated data submitted by other actors. XSS in HTTP Headers attacks target the HTTP headers which are hidden from most users and may not be validated by web applications. [Survey the application for public links] Using a browser or an automated tool, an adversary follows all public links on a web site. They record all the entry points (input) that becomes part of generated HTTP header (not only GET/POST/COOKIE, but also Content-Type, etc.) [Probe identified potential entry points for XSS vulnerability] [Craft malicious XSS URL] Once the adversary has determined which parameters are vulnerable to XSS, they will craft a malicious URL containing the XSS exploit. The adversary can have many goals, from stealing session IDs, cookies, credentials, and page content from the victim. [Get victim to click URL] In order for the attack to be successful, the victim needs to access the malicious URL.