cve.bz

CAPEC-591

Reflected XSS

Very High severityHigh likelihoodDetailed pattern

This type of attack is a form of Cross-Site Scripting (XSS) where a malicious script is "reflected" off a vulnerable web application and then executed by a victim's browser. The process starts with an adversary delivering a malicious script to a victim and convincing the victim to send the script to the vulnerable web application.

On this page

The most common method of this is through a phishing email where the adversary embeds the malicious script with a URL that the victim then clicks on. In processing the subsequent request, the vulnerable web application incorrectly considers the malicious script as valid input and uses it to creates a reposnse that is then sent back to the victim. To launch a successful Reflected XSS attack, an adversary looks for places where user-input is used directly in the generation of a response. This often involves elements that are not expected to host scripts such as image tags (<img>), or the addition of event attibutes such as onload and onmouseover. These elements are often not subject to the same input validation, output encoding, and other content filtering and checking routines.

Ask an AI about this attack pattern

ChatGPTClaudeGoogle AI Mode

Show the promptExplain the attack pattern CAPEC-591: Reflected XSS: how it unfolds, what it needs and how to prevent and detect it in my systems. Use https://capec.mitre.org/data/definitions/591.html and https://cve.bz/cve/capec/591?via=ask-ai-copy, which lists recent CVEs with the weaknesses it exploits. Cite the sources.

Opens a third-party assistant; its answer is its own, not cve.bz's. The prompt holds only this attack pattern's id and public links.

How the attack unfolds

  1. Explore

    The attacker looks for a way in.

    1. [Survey the application for user-controllable inputs] Using a browser or an automated tool, an adversary follows all public links and actions on a web site. They record all the links, the forms, the resources accessed and all other potential entry-points for the web application.

      3 techniques
      • Use a spidering tool to follow and record all links and analyze the web pages to find entry points. Make special note of any links that include parameters in the URL.
      • Use a proxy tool to record all links visited during a manual traversal of the web application.
      • Use a browser to manually explore the website and analyze how it is constructed. Many browsers' plugins are available to facilitate the analysis or automate the discovery.

  2. Experiment

    They probe what they found.

    1. [Probe identified potential entry points for reflected XSS vulnerability] The adversary uses the entry points gathered in the "Explore" phase as a target list and injects various common script payloads and special characters to determine if an entry point actually represents a vulnerability and to characterize the extent to which the vulnerability can be exploited.

      3 techniques
      • Use a list of XSS probe strings to inject script in parameters of known URLs. If possible, the probe strings contain a unique identifier.
      • Use a proxy tool to record results of manual input of XSS probes in known URLs.
      • Use a list of HTML special characters to inject into parameters of known URLs and check if they were properly encoded, replaced, or filtered out.

    2. [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.

      2 techniques
      • Change a URL parameter to include a malicious script tag.
      • Send information gathered from the malicious script to a remote endpoint.

  3. Exploit

    They carry out the attack.

    1. [Get victim to click URL] In order for the attack to be successful, the victim needs to access the malicious URL.

      2 techniques
      • Send a phishing email to the victim containing the malicious URL. This can be hidden in a hyperlink as to not show the full URL, which might draw suspicion.
      • Put the malicious URL on a public forum, where many victims might accidentally click the link.

Prerequisites

  • An application that leverages a client-side web browser with scripting enabled.

  • An application that fail to adequately sanitize or encode untrusted input.

Skills required

  • Medium skill

    Requires the ability to write malicious scripts and embed them into HTTP requests.

Resources required

  • None: No specialized resources are required to execute this type of attack.

Consequences

What a successful attack can lead to
ImpactAffectsNote
Read DataConfidentialityA successful Reflected XSS attack can enable an adversary to exfiltrate sensitive information from the application.
Gain PrivilegesConfidentiality, Authorization, Access ControlA successful Reflected XSS attack can enable an adversary to elevate their privilege level and access functionality they should not otherwise be allowed to access.
Execute Unauthorized CommandsConfidentiality, Integrity, AvailabilityA successful Reflected attack can enable an adversary run arbitrary code of their choosing, thus enabling a complete compromise of the application.
Modify DataIntegrityA successful Reflected attack can allow an adversary to tamper with application data.

Mitigations

  • Use browser technologies that do not allow client-side scripting.

  • Utilize strict type, character, and encoding enforcement.

  • Ensure that all user-supplied input is validated before use.

Weaknesses it exploits

  • CWE-79 Improper Neutralization of Input During Web Page Generation

Recent CVEs with these weaknesses

  1. 8.1CVE-2026-12574

    Zoho Corporation ManageEngine DDI Central versions 6200 and below are vulnerable to Server-side HTML/JavaScript injection in analytics PDF generation leading to local file disclosure.

  2. 5.1CVE-2026-120350

    The Vaadin Rich Text Editor exports a video embed without escaping its value, and then parses the resulting HTML into live DOM. A value crafted to break out of the href attribute therefore runs script in the viewer's browser. An attacker w…

  3. 6.4CVE-2026-60043

    An unauthenticated remote attacker can perform a XSS attack on a logged in backend user allowing for execution of multiple critical system actions. This could allow an attacker to shutdown the server or restore an uploaded backup. This can…

  4. 7.2CVE-2026-93427

    The ARMember Premium – Membership Plugin, Content Restriction, Member Levels, User Profile & User signup plugin for WordPress is vulnerable to Stored Cross-Site Scripting via Registration Custom Field (Profile Cover) in all versions up to,…

  5. 7.2CVE-2026-84938

    The Avada (Fusion) Builder plugin for WordPress is vulnerable to Stored Cross-Site Scripting via Form Notification Dynamic-Data action_hook → Media Upload Chain (ID3 Metadata / html_attributes) in all versions up to, and including, 3.16.1 …

  6. 7.4CVE-2026-115640

    LimeSurvey Community Edition 7.7.0 contains a stored cross-site scripting vulnerability in the Central Participants Database blocklist control. An authenticated user with only global participantpanel:import permission can import a CSV part…

  7. 2.0CVE-2026-125082

    A security flaw has been discovered in sunkaifei FlyCMS up to e71738e0cfb7ffd48c2ce74242a2dbb43f84f25a. Affected by this vulnerability is the function ModelDataService.insertData of the file articles/detail.html of the component Content Re…

  8. 6.1CVE-2026-120016

    SAP NetWeaver Visual Composer does not perform sufficient input validation and output encoding on certain request data. An unauthenticated attacker could craft a malicious link containing specially crafted input. If a victim clicks the lin…

The newest records naming one of them. Each weakness's page lists them all.

Part of
More specific patterns

Examples

Consider a web application that enables or disables some of the fields of a form on the page via the use of a…

Consider a web application that enables or disables some of the fields of a form on the page via the use of a mode parameter provided on the query string.

http://my.site.com/aform.html?mode=full

The application’s server-side code may want to display this mode value in the HTML page being created to give the users an understanding of what mode they are in. In this example, PHP is used to pull the value from the URL and generate the desired HTML.

<?php
echo 'Mode is: ' . $_GET["mode"];
?>

Notice how the value provided on the URL is used directly with no input validation performed and no output encoding in place. A maliciously crafted URL can thus be formed such that if a victim clicked on the URL, a malicious script would then be executed by the victim’s browser:

http://my.site.com/aform.html?mode=<script>alert('hi');</script>

Reflected XSS attacks can take advantage of HTTP headers to compromise a victim. For example, assume a vulner…

Reflected XSS attacks can take advantage of HTTP headers to compromise a victim. For example, assume a vulnerable web application called ‘mysite’ dynamically generates a link using an HTTP header such as HTTP_REFERER. Code somewhere in the application could look like:

<?php
echo "<a href="$_SERVER['HTTP_REFERER']">Test URL</a>"
?>

The HTTP_REFERER header is populated with the URI that linked to the currently executing page. A web site can be created and hosted by an adversary that takes advantage of this by adding a reference to the vulnerable web application. By tricking a victim into clicking a link that executes the attacker’s web page, such as:

"http://attackerswebsite.com?<script>malicious content</script>"

The vulnerable web application ('mysite') is now called via the attacker's web site, initiated by the victim's web browser. The HTTP_REFERER header will contain a malicious script, which is embedded into the page by the vulnerable application and served to the victim. The victim’s web browser then executes the injected script, thus compromising the victim’s machine.

MITRE's words, unchanged: CAPEC-591 at MITRE. CAPEC is Copyright © 2007–2026, The MITRE Corporation, used under the CAPEC terms of use: “The MITRE Corporation (MITRE) hereby grants you a non-exclusive, royalty-free license to use Common Attack Pattern Enumeration and Classification (CAPEC™) for research, development, and commercial purposes. Any copy you make for such purposes is authorized provided that you reproduce MITRE’s copyright designation and this license in any such copy.” CAPEC and the CAPEC logo are trademarks of The MITRE Corporation. Credits. All attack patterns.