deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-42ph-pf9q-cr72
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 8.6.41
Patched in: 8.6.41

Summary: Parse Server has a stored XSS filter bypass via Content-Type MIME parameter and missing XML extension blocklist entries

Details:
### Impact

An attacker who is allowed to upload files can bypass the file extension filter by appending a MIME parameter (e.g. `;charset=utf-8`) to the `Content-Type` header. This causes the extension validation to fail matching against the blocklist, allowing active content to be stored and served under the application's domain. In addition, certain XML-based file extensions that can render scripts in web browsers are not included in the default blocklist.

This can lead to stored XSS attacks, compromising session tokens, user credentials, or other sensitive data accessible via the browser's local storage.

### Patches

The fix strips MIME parameters from the `Content-Type` header before validating the file extension against the blocklist. The default blocklist has also been extended to include additional XML-based extensions (`xsd`, `rng`, `rdf`, `rdf+xml`, `owl`, `mathml`, `mathml+xml`) that can render active content in web browsers.

Note that the `fileUpload.fileExtensions` option is intended to be configured as an allowlist of file extensions that are valid for a specific application, not as a denylist. The default denylist is provided only as a basic default that covers most common problematic extensions. It is not intended to be an exhaustive list of all potentially dangerous extensions. Developers should not rely on the default value, as new extensions that can render active content in browsers might emerge in the future.

### Workarounds

Configure the `fileUpload.fileExtensions` option to use an allowlist of only the file extensions that your application needs, rather than relying on the default blocklist.
GitHub Security Advisory: GHSA-42ph-pf9q-cr72
Package: parse-server (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 9.0.0, < 9.6.0-alpha.15
Patched in: 9.6.0-alpha.15

Summary: Parse Server has a stored XSS filter bypass via Content-Type MIME parameter and missing XML extension blocklist entries

Details:
### Impact

An attacker who is allowed to upload files can bypass the file extension filter by appending a MIME parameter (e.g. `;charset=utf-8`) to the `Content-Type` header. This causes the extension validation to fail matching against the blocklist, allowing active content to be stored and served under the application's domain. In addition, certain XML-based file extensions that can render scripts in web browsers are not included in the default blocklist.

This can lead to stored XSS attacks, compromising session tokens, user credentials, or other sensitive data accessible via the browser's local storage.

### Patches

The fix strips MIME parameters from the `Content-Type` header before validating the file extension against the blocklist. The default blocklist has also been extended to include additional XML-based extensions (`xsd`, `rng`, `rdf`, `rdf+xml`, `owl`, `mathml`, `mathml+xml`) that can render active content in web browsers.

Note that the `fileUpload.fileExtensions` option is intended to be configured as an allowlist of file extensions that are valid for a specific application, not as a denylist. The default denylist is provided only as a basic default that covers most common problematic extensions. It is not intended to be an exhaustive list of all potentially dangerous extensions. Developers should not rely on the default value, as new extensions that can render active content in browsers might emerge in the future.

### Workarounds

Configure the `fileUpload.fileExtensions` option to use an allowlist of only the file extensions that your application needs, rather than relying on the default blocklist.
GitHub Security Advisory: GHSA-6ggm-pwr9-r5h2
Package: @leanprover/unicode-input-component (NPM)
Severity: LOW (CVSS 0.0)
CWE: CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
Vulnerable versions: < 0.2.0
Patched in: 0.2.0

Summary: XSS in @leanprover/unicode-input-component

Details:
### Impact
Projects that use [@leanprover/unicode-input-component](https://www.npmjs.com/package/@leanprover/unicode-input-component) are vulnerable to an XSS exploit in 0.1.9 of the package and lower. 
The component re-inserted text in the input element back into the input element as unescaped HTML.

### Patches
The issue has been resolved in 0.2.0.

### Workarounds
Replace the unicode input component with a basic HTML text field.
GitHub Security Advisory: GHSA-v3r3-4qgc-vw66
Package: @dicebear/converter (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 9.4.0
Patched in: 9.4.0

Summary: Uncontrolled memory allocation via crafted SVG dimensions in @dicebear/converter

Details:
### Impact

The `ensureSize()` function in `@dicebear/converter` (versions < 9.4.0) read the `width` and `height` attributes from the input SVG to determine the output canvas size for rasterization (PNG, JPEG, WebP, AVIF). An attacker who can supply a crafted SVG with extremely large dimensions (e.g. `width="999999999"`) could force the server to allocate excessive memory, leading to denial of service.

This primarily affects server-side applications that pass **untrusted or user-supplied SVGs** to the converter's `toPng()`, `toJpeg()`, `toWebp()`, or `toAvif()` functions. Applications that only convert self-generated DiceBear avatars are not practically exploitable, but are still recommended to upgrade.

### Patches

Fixed in version **9.4.0**. The `ensureSize()` function no longer reads SVG attributes to determine output size. Instead, a new `size` option (default: 512, max: 2048) controls the output dimensions. Invalid values (NaN, negative, zero, Infinity) fall back to the default.

### Workarounds

If upgrading is not immediately possible, validate and sanitize the `width` and `height` attributes of any untrusted SVG input before passing it to the converter.
GitHub Security Advisory: GHSA-gmq8-994r-jv83
Package: yauzl (NPM)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-193: Off-by-one Error
Vulnerable versions: = 3.2.0
Patched in: 3.2.1

Summary: yauzl contains an off-by-one error

Details:
yauzl (aka Yet Another Unzip Library) version 3.2.0 for Node.js contains an off-by-one error in the NTFS extended timestamp extra field parser within the getLastModDate() function. The while loop condition checks cursor < data.length + 4 instead of cursor + 4 <= data.length, allowing readUInt16LE() to read past the buffer boundary. A remote attacker can cause a denial of service (process crash via ERR_OUT_OF_RANGE exception) by sending a crafted zip file with a malformed NTFS extra field. This affects any Node.js application that processes zip file uploads and calls entry.getLastModDate() on parsed entries. Fixed in version 3.2.1.
GitHub Security Advisory: GHSA-hqjg-pww4-pcgq
Package: @google/clasp (NPM)
Severity: HIGH (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 3.2.0
Patched in: 3.2.0

Summary: @google/clasp vulnerable to unsafe path traversal cloning or pulling a malicious script

Details:
### Impact
Allows an attacker to perform a "Path Traversal" attack to modify files outside the projects directory, potentially allowing for running attacker code on the developer's machine.

### Patches
Fixed in version 3.2.0

### Workarounds
* Only clone or pull scripts from trusted sources
* Review the output of the `pull` and `clone` commands to verify only expected project files are modified
GitHub Security Advisory: GHSA-g93w-mfhg-p222
Package: @angular/compiler (NPM)
Severity: HIGH (CVSS 9.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 20.0.0-next.0.0.0, < 20.3.18
Patched in: 20.3.18

Summary: Angular vulnerable to XSS in i18n attribute bindings

Details:
A Cross-Site Scripting (XSS) vulnerability has been identified in the Angular runtime and compiler. It occurs when the application uses a security-sensitive attribute (for example href on an anchor tag) together with Angular's ability to internationalize attributes. Enabling internationalization for the sensitive attribute by adding `i18n-<attribute>` name bypasses Angular's built-in sanitization mechanism, which when combined with a data binding to untrusted user-generated data can allow an attacker to inject a malicious script. 

The following example illustrates the issue:
```html
<a href="{{maliciousUrl}}" i18n-href>Click me</a>
```

The following attributes have been confirmed to be vulnerable:
- `action`
- `background`
- `cite`
- `codebase`
- `data`
- `formaction`
- `href`
- `itemtype`
- `longdesc`
- `poster`
- `src`
- `xlink:href`

### Impact
When exploited, this vulnerability allows an attacker to execute arbitrary code within the context of the vulnerable application's domain. This enables:
- Session Hijacking: Stealing session cookies and authentication tokens.
- Data Exfiltration: Capturing and transmitting sensitive user data.
- Unauthorized Actions: Performing actions on behalf of the user.

### Attack Preconditions
1. The application must use a vulnerable version of Angular.
2. The application must bind unsanitized user input to one of the attributes mentioned above.
3. The bound value must be marked for internationalization via the presence of a `i18n-<name>` attribute on the same element.

### Patches
- 22.0.0-next.3
- 21.2.4
- 20.3.18
- 19.2.20

### Workarounds
The primary workaround is to ensure that any data bound to the vulnerable attributes is **never sourced from untrusted user input** (e.g., database, API response, URL parameters) until the patch is applied, or when it is, it shouldn't be marked for internationalization.

Alternatively, users can explicitly sanitize their attributes by passing them through Angular's `DomSanitizer`:
```ts
import {Component, inject, SecurityContext} from '@angular/core';
import {DomSanitizer} from '@angular/platform-browser';

@Component({
  template: `
    <form action="{{url}}" i18n-action>
      <button>Submit</button>
    </form>
  `,
})
export class App {
  url: string;

  constructor() {
    const dangerousUrl = 'javascript:alert(1)';
    const sanitizer = inject(DomSanitizer);
    this.url = sanitizer.sanitize(SecurityContext.URL, dangerousUrl) || '';
  }
}
```

### References
- [Fix 1](https://github.com/angular/angular/pull/67541) 
- [Fix 2](https://github.com/angular/angular/pull/67561)
GitHub Security Advisory: GHSA-g93w-mfhg-p222
Package: @angular/compiler (NPM)
Severity: HIGH (CVSS 9.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 21.0.0-next.0, < 21.2.4
Patched in: 21.2.4

Summary: Angular vulnerable to XSS in i18n attribute bindings

Details:
A Cross-Site Scripting (XSS) vulnerability has been identified in the Angular runtime and compiler. It occurs when the application uses a security-sensitive attribute (for example href on an anchor tag) together with Angular's ability to internationalize attributes. Enabling internationalization for the sensitive attribute by adding `i18n-<attribute>` name bypasses Angular's built-in sanitization mechanism, which when combined with a data binding to untrusted user-generated data can allow an attacker to inject a malicious script. 

The following example illustrates the issue:
```html
<a href="{{maliciousUrl}}" i18n-href>Click me</a>
```

The following attributes have been confirmed to be vulnerable:
- `action`
- `background`
- `cite`
- `codebase`
- `data`
- `formaction`
- `href`
- `itemtype`
- `longdesc`
- `poster`
- `src`
- `xlink:href`

### Impact
When exploited, this vulnerability allows an attacker to execute arbitrary code within the context of the vulnerable application's domain. This enables:
- Session Hijacking: Stealing session cookies and authentication tokens.
- Data Exfiltration: Capturing and transmitting sensitive user data.
- Unauthorized Actions: Performing actions on behalf of the user.

### Attack Preconditions
1. The application must use a vulnerable version of Angular.
2. The application must bind unsanitized user input to one of the attributes mentioned above.
3. The bound value must be marked for internationalization via the presence of a `i18n-<name>` attribute on the same element.

### Patches
- 22.0.0-next.3
- 21.2.4
- 20.3.18
- 19.2.20

### Workarounds
The primary workaround is to ensure that any data bound to the vulnerable attributes is **never sourced from untrusted user input** (e.g., database, API response, URL parameters) until the patch is applied, or when it is, it shouldn't be marked for internationalization.

Alternatively, users can explicitly sanitize their attributes by passing them through Angular's `DomSanitizer`:
```ts
import {Component, inject, SecurityContext} from '@angular/core';
import {DomSanitizer} from '@angular/platform-browser';

@Component({
  template: `
    <form action="{{url}}" i18n-action>
      <button>Submit</button>
    </form>
  `,
})
export class App {
  url: string;

  constructor() {
    const dangerousUrl = 'javascript:alert(1)';
    const sanitizer = inject(DomSanitizer);
    this.url = sanitizer.sanitize(SecurityContext.URL, dangerousUrl) || '';
  }
}
```

### References
- [Fix 1](https://github.com/angular/angular/pull/67541) 
- [Fix 2](https://github.com/angular/angular/pull/67561)
GitHub Security Advisory: GHSA-g93w-mfhg-p222
Package: @angular/compiler (NPM)
Severity: HIGH (CVSS 9.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 22.0.0-next.0, < 22.0.0-next.3
Patched in: 22.0.0-next.3

Summary: Angular vulnerable to XSS in i18n attribute bindings

Details:
A Cross-Site Scripting (XSS) vulnerability has been identified in the Angular runtime and compiler. It occurs when the application uses a security-sensitive attribute (for example href on an anchor tag) together with Angular's ability to internationalize attributes. Enabling internationalization for the sensitive attribute by adding `i18n-<attribute>` name bypasses Angular's built-in sanitization mechanism, which when combined with a data binding to untrusted user-generated data can allow an attacker to inject a malicious script. 

The following example illustrates the issue:
```html
<a href="{{maliciousUrl}}" i18n-href>Click me</a>
```

The following attributes have been confirmed to be vulnerable:
- `action`
- `background`
- `cite`
- `codebase`
- `data`
- `formaction`
- `href`
- `itemtype`
- `longdesc`
- `poster`
- `src`
- `xlink:href`

### Impact
When exploited, this vulnerability allows an attacker to execute arbitrary code within the context of the vulnerable application's domain. This enables:
- Session Hijacking: Stealing session cookies and authentication tokens.
- Data Exfiltration: Capturing and transmitting sensitive user data.
- Unauthorized Actions: Performing actions on behalf of the user.

### Attack Preconditions
1. The application must use a vulnerable version of Angular.
2. The application must bind unsanitized user input to one of the attributes mentioned above.
3. The bound value must be marked for internationalization via the presence of a `i18n-<name>` attribute on the same element.

### Patches
- 22.0.0-next.3
- 21.2.4
- 20.3.18
- 19.2.20

### Workarounds
The primary workaround is to ensure that any data bound to the vulnerable attributes is **never sourced from untrusted user input** (e.g., database, API response, URL parameters) until the patch is applied, or when it is, it shouldn't be marked for internationalization.

Alternatively, users can explicitly sanitize their attributes by passing them through Angular's `DomSanitizer`:
```ts
import {Component, inject, SecurityContext} from '@angular/core';
import {DomSanitizer} from '@angular/platform-browser';

@Component({
  template: `
    <form action="{{url}}" i18n-action>
      <button>Submit</button>
    </form>
  `,
})
export class App {
  url: string;

  constructor() {
    const dangerousUrl = 'javascript:alert(1)';
    const sanitizer = inject(DomSanitizer);
    this.url = sanitizer.sanitize(SecurityContext.URL, dangerousUrl) || '';
  }
}
```

### References
- [Fix 1](https://github.com/angular/angular/pull/67541) 
- [Fix 2](https://github.com/angular/angular/pull/67561)
GitHub Security Advisory: GHSA-g93w-mfhg-p222
Package: @angular/core (NPM)
Severity: HIGH (CVSS 9.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 20.0.0-next.0.0.0, < 20.3.18
Patched in: 20.3.18

Summary: Angular vulnerable to XSS in i18n attribute bindings

Details:
A Cross-Site Scripting (XSS) vulnerability has been identified in the Angular runtime and compiler. It occurs when the application uses a security-sensitive attribute (for example href on an anchor tag) together with Angular's ability to internationalize attributes. Enabling internationalization for the sensitive attribute by adding `i18n-<attribute>` name bypasses Angular's built-in sanitization mechanism, which when combined with a data binding to untrusted user-generated data can allow an attacker to inject a malicious script. 

The following example illustrates the issue:
```html
<a href="{{maliciousUrl}}" i18n-href>Click me</a>
```

The following attributes have been confirmed to be vulnerable:
- `action`
- `background`
- `cite`
- `codebase`
- `data`
- `formaction`
- `href`
- `itemtype`
- `longdesc`
- `poster`
- `src`
- `xlink:href`

### Impact
When exploited, this vulnerability allows an attacker to execute arbitrary code within the context of the vulnerable application's domain. This enables:
- Session Hijacking: Stealing session cookies and authentication tokens.
- Data Exfiltration: Capturing and transmitting sensitive user data.
- Unauthorized Actions: Performing actions on behalf of the user.

### Attack Preconditions
1. The application must use a vulnerable version of Angular.
2. The application must bind unsanitized user input to one of the attributes mentioned above.
3. The bound value must be marked for internationalization via the presence of a `i18n-<name>` attribute on the same element.

### Patches
- 22.0.0-next.3
- 21.2.4
- 20.3.18
- 19.2.20

### Workarounds
The primary workaround is to ensure that any data bound to the vulnerable attributes is **never sourced from untrusted user input** (e.g., database, API response, URL parameters) until the patch is applied, or when it is, it shouldn't be marked for internationalization.

Alternatively, users can explicitly sanitize their attributes by passing them through Angular's `DomSanitizer`:
```ts
import {Component, inject, SecurityContext} from '@angular/core';
import {DomSanitizer} from '@angular/platform-browser';

@Component({
  template: `
    <form action="{{url}}" i18n-action>
      <button>Submit</button>
    </form>
  `,
})
export class App {
  url: string;

  constructor() {
    const dangerousUrl = 'javascript:alert(1)';
    const sanitizer = inject(DomSanitizer);
    this.url = sanitizer.sanitize(SecurityContext.URL, dangerousUrl) || '';
  }
}
```

### References
- [Fix 1](https://github.com/angular/angular/pull/67541) 
- [Fix 2](https://github.com/angular/angular/pull/67561)
GitHub Security Advisory: GHSA-g93w-mfhg-p222
Package: @angular/core (NPM)
Severity: HIGH (CVSS 9.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 21.0.0-next.0, < 21.2.4
Patched in: 21.2.4

Summary: Angular vulnerable to XSS in i18n attribute bindings

Details:
A Cross-Site Scripting (XSS) vulnerability has been identified in the Angular runtime and compiler. It occurs when the application uses a security-sensitive attribute (for example href on an anchor tag) together with Angular's ability to internationalize attributes. Enabling internationalization for the sensitive attribute by adding `i18n-<attribute>` name bypasses Angular's built-in sanitization mechanism, which when combined with a data binding to untrusted user-generated data can allow an attacker to inject a malicious script. 

The following example illustrates the issue:
```html
<a href="{{maliciousUrl}}" i18n-href>Click me</a>
```

The following attributes have been confirmed to be vulnerable:
- `action`
- `background`
- `cite`
- `codebase`
- `data`
- `formaction`
- `href`
- `itemtype`
- `longdesc`
- `poster`
- `src`
- `xlink:href`

### Impact
When exploited, this vulnerability allows an attacker to execute arbitrary code within the context of the vulnerable application's domain. This enables:
- Session Hijacking: Stealing session cookies and authentication tokens.
- Data Exfiltration: Capturing and transmitting sensitive user data.
- Unauthorized Actions: Performing actions on behalf of the user.

### Attack Preconditions
1. The application must use a vulnerable version of Angular.
2. The application must bind unsanitized user input to one of the attributes mentioned above.
3. The bound value must be marked for internationalization via the presence of a `i18n-<name>` attribute on the same element.

### Patches
- 22.0.0-next.3
- 21.2.4
- 20.3.18
- 19.2.20

### Workarounds
The primary workaround is to ensure that any data bound to the vulnerable attributes is **never sourced from untrusted user input** (e.g., database, API response, URL parameters) until the patch is applied, or when it is, it shouldn't be marked for internationalization.

Alternatively, users can explicitly sanitize their attributes by passing them through Angular's `DomSanitizer`:
```ts
import {Component, inject, SecurityContext} from '@angular/core';
import {DomSanitizer} from '@angular/platform-browser';

@Component({
  template: `
    <form action="{{url}}" i18n-action>
      <button>Submit</button>
    </form>
  `,
})
export class App {
  url: string;

  constructor() {
    const dangerousUrl = 'javascript:alert(1)';
    const sanitizer = inject(DomSanitizer);
    this.url = sanitizer.sanitize(SecurityContext.URL, dangerousUrl) || '';
  }
}
```

### References
- [Fix 1](https://github.com/angular/angular/pull/67541) 
- [Fix 2](https://github.com/angular/angular/pull/67561)