CAPEC-592

Initially presented by an adversary to the vulnerable web application, the malicious script is incorrectly considered valid input and is not properly encoded by the web application. A victim is then convinced to use the web application in a way that creates a response that includes the malicious script. This response is subsequently sent to the victim and the malicious script is executed by the victim's browser. To launch a successful Stored XSS attack, an adversary looks for places where stored input data is used 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 attributes 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.

How the attack unfolds

1. Explore

   The attacker looks for a way in.

   1. [Survey the application for stored 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. The adversary is looking for areas where user input is stored, such as user profiles, shopping carts, file managers, forums, blogs, and logs.

      3 techniques

      • Use a spidering tool to follow and record all links and analyze the web pages to find entry points.
      • 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.

   2. [Probe identified potential entry points for stored 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.

      2 techniques

      • Use a list of XSS probe strings to submit script in input fields that could be stored by the web application. If possible, the probe strings contain a unique identifier so they can be queried for after submitting to see if they are stored.
      • Use a list of HTML special characters to submit in input fields that could be stored by the web application and check if they were properly encoded, replaced, or filtered out.

   3. [Store malicious XSS content] Once the adversary has determined which stored locations are vulnerable to XSS, they will interact with the web application to store the malicious content. The adversary can have many goals, from stealing session IDs, cookies, credentials, and page content from a victim.

      2 techniques

      • Store a malicious script on a page that will execute when viewed by the victim.
      • Use a tool such as BeEF to store a hook into the web application. This will alert the adversary when the victim has accessed the content and will give the adversary control over the victim's browser, allowing them access to cookies, user screenshot, user clipboard, and more complex XSS attacks.

3. Exploit

   They carry out the attack.

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

      2 techniques

      • Send a phishing email to the victim containing a URL that will direct them to the malicious stored content.
      • Simply wait for a victim to view the content. This is viable in situations where content is posted to a popular public forum.

Prerequisites

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

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

• An application that stores information provided by the user in data storage of some kind.

Skills required

• Medium skill

  Requires the ability to write scripts of varying complexity and to inject them through user controlled fields within the application.

Resources required

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

Consequences

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 being stored.

Weaknesses it exploits

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

Recent CVEs with these weaknesses

1. 8.1CVE-2026-125742026-11-10

   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-1203502026-11-10

   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-600432026-11-10

   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-934272026-11-10

   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-849382026-11-10

   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-1156402026-11-10

   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-1250822026-11-10

   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-1200162026-11-10

   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.

Related attack patterns

Part of

• CAPEC-63 Cross-Site Scripting (XSS)

More specific patterns

• CAPEC-18 XSS Targeting Non-Script Elements
• CAPEC-32 XSS Through HTTP Query Strings
• CAPEC-86 XSS Through HTTP Headers
• CAPEC-198 XSS Targeting Error Pages
• CAPEC-199 XSS Using Alternate Syntax
• CAPEC-209 XSS Using MIME Type Mismatch
• CAPEC-243 XSS Targeting HTML Attributes
• CAPEC-244 XSS Targeting URI Placeholders
• CAPEC-245 XSS Using Doubled Characters
• CAPEC-247 XSS Using Invalid Characters

Examples

MITRE's words, unchanged: CAPEC-592 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.