Отправить #1026976: https://github.com/nliautaud/pico-content-editor pico-content-editor 02d5ad6c820c5050c542ab9505819b5e0a0ba1af Cross-Site Request Forgery

**Summary:** PicoContentEditor's content-save and file-upload request handlers perform no CSRF token validation and the server never checks the Origin or Referer headers. A cross-site POST request from an attacker-controlled page is processed exactly like a legitimate same-site request, as long as the victim's browser sends a valid session cookie. This flaw is independent of, and persists even after correctly applying the official mitigation (installing the PicoUsers plugin) for the previously reported unauthenticated-upload vulnerability in the same plugin.

**Vulnerable component:** PicoContentEditor content-save and file-upload request handlers (src/Edits.php, src/Uploads.php, PicoContentEditor.php)

**Affected file(s) and parameter(s):** src/Edits.php (saveMeta(), saveRegions()); src/Uploads.php (saveFile()); PicoContentEditor.php (processPageEdits(), processOverallEdits()); HTTP POST field "PicoContentEditor" (JSON) and multipart field "PicoContentEditorUpload" sent to the Pico site root

**Technical description:** The only check performed before processing a save or upload request is Auth::can(Auth::SAVE) / Auth::can(Auth::UPLOAD), which answers "is this session authorized to perform this action," never "did this request actually originate from the application's own pages." A full-text search of the plugin's PHP source for csrf, samesite, origin, and referer returns zero matches outside of unrelated bundled third-party JavaScript assets, confirming the complete absence of CSRF protection anywhere in this request-handling path. The victim must hold an authorized session, which includes both the plugin's default insecure configuration (no PicoUsers installed, where every visitor is implicitly authorized) and a correctly configured PicoUsers setup where a legitimate editor or admin happens to be logged in at the time. In the evaluated environment, PHP's session.cookie_samesite setting is empty, meaning any protection against this flaw currently depends entirely on the visiting browser's own default cookie-handling behavior rather than anything enforced by the application itself.

**Steps to reproduce:**
1. Install the PicoContentEditor plugin into a Pico CMS instance (with or without PicoUsers; the flaw is identical either way).
2. Send a POST / request to the site root with the body field PicoContentEditor=<json-payload> (e.g. {"meta":"Title: PWNED\n"}), setting the Origin and Referer headers to a domain unrelated to the target site, exactly as a browser would send them when submitting a cross-site auto-submitting HTML form.
3. Observe that the server accepts and applies the change despite the mismatched Origin/Referer, and that the target page's content subsequently reflects the attacker-supplied value.

**Impact:** An attacker who lures an authorized PicoContentEditor user (or, in an unprotected default install, any visitor) to a malicious web page can silently tamper with site content, overwriting page titles, descriptions, and other front-matter fields, or planting uploaded files, using the victim's own authorization and without their knowledge. No special privileges are required of the attacker; impact depends entirely on the victim's own session state.

**Visual proof:** csrf_execution.png (within the researcher's disclosure package); confirmed server response during testing: {"status":[{"state":true,"message":"Page meta saved..."}...}, with the target page's title subsequently showing the attacker-controlled value "PWNED-BY-CSRF-...".

• Источник: ⚠️ https://github.com/vinniboy021-blip/Advisory/blob/main/csrf-pico-save-upload.md
• Пользователь: vinniboy021 (UID 100165)
• Представление: 13.10.2026 03:35 (23 дни назад)
• Модерация: 04.11.2026 19:19 (23 days later)
• Статус: принято
• Запись VulDB: 431149 [nliautaud pico-content-editor до 02d5ad6c820c5050c542ab9505819b5e0a0ba1af подделка межсайтовых запросов]
• Баллы: 20