| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Yamcs is a mission control framework. Prior to 5.9.4, Yamcs reflects an attacker-controlled redirect_uri parameter from GET /auth/authorize into yamcs-core/src/main/resources/auth/templates/authorize.html without adequate HTML escaping by yamcs-core/src/main/java/org/yamcs/http/auth/AuthHandler.java and yamcs-core/src/main/java/org/yamcs/http/HandlerContext.java. A crafted authorization URL can execute JavaScript when opened by a Yamcs user. The script can access browser-held authentication material and transmit it to an attacker, enabling account compromise. This issue is fixed in version 5.9.4. |
| Unauthenticated Cross Site Scripting (XSS) in Uncode <= 2.12.7 versions. |
| Spring Authorization Server's default consent page renders user-controlled values without HTML entity encoding. When using the DefaultConsentPage, an attacker can craft an OAuth2 authorization request containing a malicious value that is stored server-side and later rendered unencoded in the default consent page presented to the end user.
Spring Authorization Server 1.5.0 - 1.5.8
Spring Authorization Server 1.4.0 - 1.4.11 |
| Sulu is an open-source PHP content management system based on the Symfony framework. Prior to versions 2.6.25 and 3.0.8, src/Sulu/Bundle/MediaBundle/Controller/MediaStreamController.php allows the /media/{id}/download/{slug} route and its administration variant to honor the inline query parameter for scriptable MIME types. The vulnerable stored Content-Type values include text/html, application/xhtml+xml, text/xml, and application/xml. An attacker with media upload permission can store an HTML, XHTML, or XML document and create a link using inline=1, causing the application to return the file on the Sulu origin instead of forcing Content-Disposition attachment. When an authenticated victim opens the link, attacker-controlled JavaScript can execute with the victim's Sulu-origin session and can read data or perform actions as that victim. This issue is fixed in versions 2.6.25 and 3.0.8. |
| Cross Site Scripting vulnerability in Cockpit CMS v.2.13.5 and before allows a remote attacker to execute arbitrary code via the item.php, field-select.js and tags.js components |
| Unauthenticated Cross Site Scripting (XSS) in Email Subscribers & Newsletters <= 5.9.33 versions. |
| A security vulnerability has been detected in code-projects Employee Leave Managing System 1.0. Affected is an unknown function of the file /EmpManageSys/editaction.php of the component Employee Profile Update. The manipulation of the argument Name leads to cross site scripting. The attack can be initiated remotely. The exploit has been disclosed publicly and may be used. |
| backpack/crud provides Create, Read, Update & Delete (CRUD) functions for Backpack, a collection of Laravel packages that help users build custom administration panels. From 6.0.0 until 6.8.14 and 7.0.37, the src/app/Library/Uploaders/SingleBase64Image.php methods SingleBase64Image::uploadFiles and SingleBase64Image::uploadRepeatableFiles, used by image fields through withFiles(), accept any data URI beginning with data:image without validating the declared MIME subtype or decoded bytes, while src/app/Library/Uploaders/Support/FileNameGenerator.php method FileNameGenerator::getExtensionFromFile applies mime_content_type() to the data URI instead of the decoded content. An authenticated administrator can therefore store arbitrary file content under an extensionless filename on the configured disk, which can cause stored cross-site scripting or other unintended behavior when the file is served and accessed. This issue is fixed in version 7.0.38 and 6.8.14. |
| Insecure hardcoded credentials in the Admin account of Tenda HG21 V4.0.0-260302 allows attackers to gain root access. |
| Unauthenticated Cross Site Scripting (XSS) in WordPress Social Login and Register <= 7.8.2 versions. |
| Unauthenticated Cross Site Scripting (XSS) in RegistrationMagic <= 6.0.9.8 versions. |
| Unauthenticated Cross Site Scripting (XSS) in SliceWP <= 1.2.10 versions. |
| Unauthenticated Cross Site Scripting (XSS) in Super Store Finder <= 7.10 versions. |
| Subscriber Cross Site Scripting (XSS) in Kalles Addons <= 1.0.6 versions. |
| TechStore 1.0 is vulnerable to Cross Site Scripting (XSS). In contact_display, the application echoes the id parameter verbatim into the rendered page, permitting execution of attacker-supplied JavaScript in users browser. |
| Silverstripe Versioned provides versioning for Silverstripe models. Prior to 3.2.1, RestoreAction::getRestoreMessage() in src/RestoreAction.php builds ArchiveAdmin restore notifications rendered as CAST_HTML and inserts $restoredItem->Title, $restoredItem->URLSegment, $restoredItem->CMSEditLink(), and $changedProperty['value'] without applying Convert::raw2xml(). When an administrator restores an archived page containing a crafted title or URL segment, the generated restoration message can execute stored JavaScript in the administrator's browser, compromising the confidentiality and integrity of the CMS session. This issue is fixed in version 3.2.1. |
| NSP is vulnerable to a stored XSS due to insufficient validation or encoding of user-controlled input in a workflow application. An authenticated attacker with access to the workflow application could embed harmful code that runs when another user views the content. |
| @pdfme/schemas before 5.5.9 contains a cross-site scripting vulnerability in the Select schema plugin that fails to sanitize option values before interpolating them into HTML via innerHTML. Attackers can supply malicious templates with crafted option values containing HTML and JavaScript to execute arbitrary code in users' browsers. |
| Improper neutralization of input during web page generation in Apache Wicket.
org.apache.wicket.markup.html.form.Button clears the escape-model-strings flag in its constructor, so that the value attribute it writes is not encoded twice — ComponentTag already encodes attribute values when it writes the tag. That reasoning holds only for the attribute. When the component is attached to a <button> element rather than an <input>, it writes its model object into the element body instead, and nothing encodes an element body, so markup in the model is rendered as markup.
An application is affected where it renders a Button on a <button> element and that button's model holds data an attacker can influence. Wicket cannot determine where a model value comes from, so whether it reaches the page from a request or from storage is a property of the application. The subclasses that inherit this constructor — AjaxButton, AjaxFallbackButton and WizardButton — are affected on the same terms.
As a workaround, calling setEscapeModelStrings(true) on a button that renders as a <button> element escapes the body correctly, and does not cause double encoding, because the value attribute is written only for <input> elements.
This issue affects Apache Wicket: from 8.0.0 through 8.18.0, from 9.0.0 through 9.23.0, from 10.0.0 through 10.10.0. Older, unsupported releases from 6.25.0 and 7.5.0 onwards are also affected.
Users are recommended to upgrade to version 8.19.0, 9.24.0 or 10.11.0, which fix the issue. |
| Improper neutralization of input during web page generation in Apache Wicket.
The <wicket:label> tag is provided by org.apache.wicket.markup.html.form.AutoLabelTextResolver, which is registered by default in every WebApplication. The resolver writes the label it finds into the markup as it is, and reads no escaping setting at all, so markup in a label is rendered as markup.
When the label comes from the labelled component's label model, set through FormComponent#setLabel(IModel), it is written to the markup unescaped. An application is affected where the label of a form component holds data an attacker can influence. Wicket cannot determine where a model value comes from, so whether it reaches the page from a request or from storage is a property of the application.
There is no workaround. Unlike every other rendering path in Wicket, the resolver never consulted the escape-model-strings setting, so an application had no way to ask for the label to be escaped.
The body of a <wicket:label> tag is markup by design and is not affected; it remains the supported way to place markup in a label.
This issue affects Apache Wicket: from 8.0.0 through 8.18.0, from 9.0.0 through 9.23.0, from 10.0.0 through 10.10.0. Older, unsupported releases from 1.5.0 onwards are also affected. Users are recommended to upgrade to version 8.19.0, 9.24.0 or 10.11.0, which fix the issue. |
