A DOM Clobbering vulnerability in tsup v8.3.4 allows attackers to execute arbitrary code via a crafted script in the import.meta.url to document.currentScript in cjs_shims.js components

**Exploitability Metrics**

Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.

Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.

Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.

Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.

User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.

**Vulnerable System Impact Metrics**

Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.

Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).

Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.

**Subsequent System Impact Metrics**

Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.

Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).

Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.

GHSA-3mv9-4h5g-vhg3: tsup DOM Clobbering vulnerability

Cross Site Scripting vulnerability in seajs v.2.2.3 allows a remote attacker to execute arbitrary code via the seajs package

GHSA-pfr4-4397-3hg8: seajs Cross-site Scripting vulnerability

A DOM Clobbering vulnerability in mavo v0.3.2 allows attackers to execute arbitrary code via supplying a crafted HTML element.

GHSA-3mf5-r4hg-hfx9: mavo DOM Clobbering vulnerability

## Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-655q-fx9r-782v. This link is maintained to preserve external references.

## Original Description
picklescan before 0.0.21 does not treat 'pip' as an unsafe global. An attacker could craft a malicious model that uses Pickle to pull in a malicious PyPI package (hosted, for example, on pypi.org or GitHub) via `pip.main()`. Because pip is not a restricted global, the model, when scanned with picklescan, would pass security checks and appear to be safe, when it could instead prove to be problematic.

GHSA-vr75-hjh9-7fr6: Duplicate Advisory: Remote Code Execution via Malicious Pickle File Bypassing Static Analysis

Security questionnaires take a lot of time and repetitively answering the same questions manually chews up business time…

Security questionnaires take a lot of time and repetitively answering the same questions manually chews up business time but automation can make the process faster. In this article, we will see what is security questionnaire automation and how you can use it to reduce response time.

**Table of Contents**

1.  Why Automate Security Questionnaires?
2.  Steps to Automate Security Questionnaires
3.  1\. Centralize Your Security Documentation
4.  2\. Use a Standardized Response Library
5.  3\. Take Advantage of Automation Tools
6.  4\. Integrate with Compliance and Security Systems
7.  5\. Assign Roles and Responsibilities
8.  Benefits of Automating Security Questionnaires
9.  How to Get Started with Automation?
10.  Conclusion 

Security questionnaire automation is the method of using technology to automate and accelerate the filling out of security questionnaires. Rather than repeatedly answering the same compliance and security questions manually, companies use automation software to auto-populate answers, handle document requests, and unify security policies easily.

****Why Automate Security Questionnaires?****

Automation accelerates the process and makes it less stressful and more efficient. Following are the reasons why companies are opting for automation:

*   **Saves Time:** It decreases the time taken to fill out questionnaires.
*   **Improves Accuracy:** Avoids human error and inconsistencies.
*   **Enhances Productivity:** Allows security teams to concentrate on critical tasks.
*   **Speeds Up Vendor Assessments:** Helps in quicker deal closures by minimizing delays.

****Steps to Automate Security Questionnaires****

Here are some steps to automate the security questionnaires:

****1\. Centralize Your Security Documentation****

Establish a centralized location for all security policies, certifications, and compliance documents. This allows easy pulling of answers in a rush.

*   Keep documents in a safe cloud-based environment.
*   Control and limit access to authorized staff.
*   Update documents frequently to account for changes in security controls.

****2\. Use a Standardized Response Library****

The majority of security questionnaires use similar questions. Rather than duplicating effort every time:

*   Develop a pre-approved response library.
*   Classify answers according to compliance frameworks (SOC 2, ISO 27001, GDPR, etc.).
*   Make answers concise, clear, and current.

****3\. Take Advantage of Automation Tools****

There are various tools to automate security questionnaires. These tools are able to:

*   Auto-populate answers based on previous submissions.
*   Provide the most appropriate answers based on your response library.
*   Integrate with compliance management platforms.

Popular automation tools are:

*   OneTrust – Orchestrates compliance and security questionnaires.
*   SecurityScorecard – Automates vendor risk assessments.
*   Loopio – Centralizes security questionnaire responses.

****4\. Integrate with Compliance and Security Systems****

Integrate your automation tool with current security systems. This guarantees:

*   Real-time synchronization of data.
*   Automatic updates when security policies are modified.
*   Quicker and more precise questionnaire answers.

****5\. Assign Roles and Responsibilities****

Human supervision is still important despite automation. Designate particular roles:

*   Security Team: Verifies responses for correctness.
*   Legal Team: Guarantees compliance with laws.
*   IT Team: Handles integration with security tools.

Well-defined accountability avoids mistakes and guarantees quality responses.

****Benefits of Automating Security Questionnaires****

The four benefits of automating security questionnaires are:

**1\. Quick Response Time**

No longer the rush to look for information. Automation drastically minimizes response time and enables companies to seal deals in less time.

**2\. Uniformity of Responses**

Automated processes provide uniform and accurate responses to every questionnaire, hence it minimizes confusion and misinterpretation.

**3\. Lower Security Team Workload**

Automation liberates security teams from repetitive security questions to undertake more strategic initiatives.

**4\. Higher Client and Partner Trust**

Quick and reliable security questionnaire responses show clients that your company prioritizes cybersecurity and compliance.

****How to Get Started with Automation?****

If you’re new to automation, start with these simple steps:

*   Audit your current questionnaire process. Identify bottlenecks.
*   Choose an automation tool that fits your needs and budget.
*   Build a response library with pre-approved answers.
*   Train your team on how to use automation tools effectively.
*   Continuously update responses to keep up with security changes.

****Conclusion** **

Security questionnaires do not have to be challenging. Companies can save time, increase accuracy, and expedite vendor approvals after automating the process of security questionnaires. The secret is to consolidate data, utilize automation tools, and institute human review. The outcome includes a quicker, more well structured security questionnaire process for all.

Featured, Top Image via Freepik

How to Automate Security Questionnaires and Reduce Response Time

### Impact
User enumeration in database authentication in Flask-AppBuilder <= 4.5.3 and werkzeug >= 3.0.0. Allows for a non authenticated user to enumerate existing usernames by timing the response time from the server when brute forcing requests to login.

### Patches

Upgrade to flask-appbuilder>=4.5.3

### Workarounds
Downgrade werkzeug to <3.0.0

### References
_Are there any links users can visit to find out more?_

1.  GitHub Advisory Database
2.  GitHub Reviewed
3.  CVE-2025-24023

**Flask-AppBuilder Observable Response Discrepancy**

Low severity GitHub Reviewed Published Mar 3, 2025 in dpgaspar/Flask-AppBuilder • Updated Mar 3, 2025

**Package**

pip flask-appbuilder (pip)

**Affected versions**

< 4.5.3

**Impact**

User enumeration in database authentication in Flask-AppBuilder <= 4.5.3 and werkzeug >= 3.0.0. Allows for a non authenticated user to enumerate existing usernames by timing the response time from the server when brute forcing requests to login.

**Patches**

Upgrade to flask-appbuilder>=4.5.3

**Workarounds**

Downgrade werkzeug to <3.0.0

**References**

_Are there any links users can visit to find out more?_

**References**

*   GHSA-p8q5-cvwx-wvwp

Published to the GitHub Advisory Database

Mar 3, 2025

GHSA-p8q5-cvwx-wvwp: Flask-AppBuilder Observable Response Discrepancy

Improper privilege management in a REST interface allowed registered users to access unauthorized resources if the resource ID was known. 

This issue affects Apache StreamPipes: through 0.95.1.

Users are recommended to upgrade to version 0.97.0 which fixes the issue.

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.

Attack complexity: More severe for the least complex attacks.

Privileges required: More severe if no privileges are required.

User interaction: More severe when no user interaction is required.

Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.

Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.

Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.

Availability: More severe when the loss of impacted component availability is highest.

GHSA-vm7w-2724-5m23: Apache StreamPipes has improper privilege management in a REST interface

Prism (aka PrismJS) through 1.29.0 allows DOM Clobbering (with resultant XSS for untrusted input that contains HTML but does not directly contain JavaScript), because document.currentScript lookup can be shadowed by attacker-injected HTML elements.

GHSA-x7hr-w5r2-h6wg: PrismJS DOM Clobbering vulnerability

Stage.js through 0.8.10 allows DOM Clobbering (with resultant XSS for untrusted input that contains HTML but does not directly contain JavaScript), because document.currentScript lookup can be shadowed by attacker-injected HTML elements.

GHSA-fp3m-g5rc-4c28: Stage.js DOM Clobbering vulnerabilty

In oxidized-web (aka Oxidized Web) before 0.15.0, the RANCID migration page allows an unauthenticated user to gain control over the Linux user account that is running oxidized-web.

Tag

#auth