Answer in brief
CVE-2026-55891 records a Low severity vulnerability in PrivateBin has reflected JSON injection in backend responses via unescaped REQUEST_URI. The current sources do not mark it as known exploited. The current feed maps privatebin/privatebin (composer). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
A CVSS score is not reported in the current record. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps privatebin/privatebin (composer). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| privatebin/privatebincomposer | <=2.0.4 | 2.0.5 |
Published upstream
Aug 28, 2026
Evidence: source:ghsa:source_dates:source-dates:recordSource modified
Aug 28, 2026
Evidence: source:ghsa:source_dates:source-dates:recordFirst seen by HOL
Aug 28, 2026
## Vulnerability Details A reflected JSON injection allows an attacker to return arbitrary data in the JSON endpoints (like ` /?jsonld=` and `/?pasteid`). ### Root Cause `Request::getRequestUri()` sanitizes `$_SERVER['REQUEST_URI']` with `FILTER_SANITIZE_URL`: ```php public function getRequestUri() { $uri = array_key_exists('REQUEST_URI', $_SERVER) ? filter_var($_SERVER['REQUEST_URI'], FILTER_SANITIZE_URL) : ''; return empty($uri) ? '/' : $uri; } ``` `FILTER_SANITIZE_URL` does **not** strip `"`, `'`, `<`, `>` characters (per the PHP manual's allowed-character list for this filter). So the raw, attacker-controlled request URI (including query string) passes through almost unmodified into `Controller::$_urlBase` (set in `_init()`). In `Controller::_jsonld()`, `$_urlBase` is spliced directly into one of the static `.jsonld` templates (`js/types.jsonld`, `js/paste.jsonld`, etc.) with a plain `str_replace()`, without any JSON-escaping: ```php $content = str_replace( '?jsonld=', $this->_urlBase . '?jsonld=', file_get_contents($file) ); ... header('Content-type: application/ld+json'); header('Access-Control-Allow-Origin: *'); header('Access-Control-Allow-Methods: GET'); echo $content; ``` A request URI containing a literal `"` therefore breaks out of the JSON string in the `"@context"."pb"` value and injects arbitrary attacker-controlled key/value pairs into the response body, which is served with `Content-Type: application/ld+json` and `Access-Control-Allow-Origin: *`. Additionally, the `jsonld` case in `Controller::__construct()` returns early: ```php case 'jsonld': $this->_jsonld($this->_request->getParam('jsonld')); return; ``` This bypasses `_setCacheHeaders()` and all of the security headers normally applied in `_view()` (notably `X-Content-Type-Options: nosniff`, CSP, `X-Frame-Options`, `Referrer-Policy`). So this is the only response path lacking `X-Content-Type-Options: nosniff`. ### Attack Scenario 1. An attacker crafts a request to the target PrivateBin instance whose request-target contains a raw `"` character, e.g.: `GET /?jsonld=types&x="injected":"pwned","y":" HTTP/1.1` (delivered via a raw socket / HTTP client that doesn't normalize the request line — most browsers percent-encode `"` in the address bar, but many HTTP libraries, proxies, and automated link-preview/structured-data crawlers do not). 2. The server reflects the raw value into the JSON-LD response, producing a syntactically broken / attacker-extended JSON document. 3. Because `Access-Control-Allow-Origin: *` is set and `X-Content-Type-Options: nosniff` is missing on this path, any origin can fetch and rely on this manipulated content, and the response loses the defense-in-depth MIME-sniffing protection applied everywhere else in the app. ### Impact Reflected, unauthenticated injection of attacker-controlled content into a CORS-open `application/ld+json` response, plus a missing `X-Content-Type-Options: nosniff` header on this single response path (present everywhere else). No direct script execution was demonstrated on current browsers (this content type is generally not HTML-sniffed), but it is a real output-encoding bug (CWE-116) and a defense-in-depth gap that could be exploited by structured-data consumers or in combination with other issues / less-strict clients. ### Vulnerable Code ```php $content = str_replace( '?jsonld=', $this->_urlBase . '?jsonld=', file_get_contents($file) ); ... header('Content-type: application/ld+json'); ``` ### Verification Dynamically confirmed on v2.0.4 (commit `597a6f0`) via `php -S 127.0.0.1:8082 index.php`: Request: ```http GET /?jsonld=types&x="injected":"pwned","y":" HTTP/1.1 Host: 127.0.0.1:8082 Connection: close ``` Unpatched response body (excerpt): ```json "pb": "/?jsonld=types&x="injected":"pwned","y":"?jsonld=types#" ``` — i.e. the `"` characters are reflected raw, breaking the JSON structure, and `X-Content-Type-Options` is absent from the response headers. After applying the fix above, the same request returns: ```json "pb": "/?jsonld=types&x=\"injected\":\"pwned\",\"y\":\"?jsonld=types#" ``` with `X-Content-Type-Options: nosniff` present, and the existing `JsonApiTest::testJsonLd*` unit test expectations (`/?jsonld=...`) remain unchanged for normal requests. ## Credits This vulnerability was reported by Iaohkut, @alanturing881, which PrivateBin would like to thank for that. In general, PrivateBin would like to thank everyone reporting issues and potential vulnerabilities to it. If you think you have found a vulnerability or potential security risk, [we'd kindly ask you to follow our security policy](https://github.com/PrivateBin/PrivateBin/blob/master/SECURITY.md) and report it to us. PrivateBin then assess the report and will take the actions PrivateBin deem necessary to address it.
Quoted source text, attributed separately from HOL analysis.