### Summary An admin who revokes or downgrades a non-admin user's permissions through pyLoad's own documented `/api/<func>` RPC surface — e.g. `POST /api/set_user_permission` (or its legacy alias `/api/setUserPermission`) — updates the target's database row but never invalidates that user's existing Flask cookie session. The demoted user keeps their pre-revocation `role`/`permission` bits on every subsequent WebUI page load and every subsequent `/api/<func>` call made with that cookie, for up to the default `session_lifetime` of ~31 days, or until they voluntarily log out. No action by the demoted user is required beyond already being logged in at the time of revocation. ### Details The vulnerable method, verbatim, at `src/pyload/core/api/__init__.py:1652-1656`: ``` @legacy("setUserPermission") @post def set_user_permission(self, user: str, permission: int, role: int) -> None: self.pyload.db.set_permission(user, permission) self.pyload.db.set_role(user, role) ``` It carries no `@permission(...)` decorator and its body never calls `clear_all_user_sessions` or any other session-invalidation routine. The **only** call site in the entire codebase that pairs a permission/role change with `clear_all_user_sessions` is the WebUI's `update_users()` route, `src/pyload/webui/app/blueprints/json_blueprint.py:442-444`: ``` api.set_user_permission(name, data["permission"], data["role"]) if was_changed: clear_all_user_sessions(name) ``` A repo-wide grep for `set_user_permission|setUserPermission` returns exactly 3 hits: the `@legacy` alias registration (`core/api/__init__.py:1652`), the method definition itself (`:1654`), and this one call site (`json_blueprint.py:442`). No other caller exists. pyLoad's own public RPC dispatcher reaches `Api.set_user_permission` directly, bypassing `json_blueprint.py` entirely. `src/pyload/webui/app/blueprints/api_blueprint.py:21-26` registers `rpc(func, args="")` on `/api/<func>` and `/api/<func>/<args>` for `GET`/`POST`; line 68 dispatches with `response = jsonify(getattr(api, func)(**json_request_body))` — i.e. it invokes any method on the `Api` object by name, including `set_user_permission` (also reachable via form/multipart bodies at `:72`/`:77`). The only authorization gate before that dispatch, at `api_blueprint.py:50`, is: ``` if not api.is_authorized(func, {"role": user_info["role"], "permission": user_info["permission"]}): ``` `is_authorized` (`core/api/__init__.py:1419-1432`) returns `True` outright when the **caller's** role is `Role.ADMIN`; otherwise it requires `func_name in perm_map`. `set_user_permission` has no `@permission` decorator, so it is absent from `perm_map` (the module comment at `core/api/__init__.py:37` states "unlisted functions are for admins only"). This gate concerns only the caller's own authorization — it says nothing about, and never touches, the **target** user's existing session. ### The stale session survives The demoted user's session was populated once, at login, and is never refreshed: - `helpers.py:170,179,183-185` — `parse_permissions(session)` derives the caller's effective admin/permission bits from `session.get("role")` and `session.get("perms")`. - These values are written once by `set_session()` (`helpers.py:223-234`), called only from `app_blueprint.py:88` (login) and `:100` (autologin). A repo-wide grep for `before_request` inside `src/pyload/` returns nothing — no hook anywhere refreshes a live session from the database. - `is_authenticated(session)` (`helpers.py:261-266`) is exactly: ``` user = session.get("name") authenticated = session.get("authenticated", False) return authenticated and api.user_exists(user) ``` It re-validates only that the username still exists — never that the session's cached `role`/`perms` still match the current database values. - Inside `apikey_auth` (`helpers.py:393-404`), when no `X-API-Key` header is supplied, `flask.g.user_info` is built as `{"id": s["id"], "name": s["name"], "role": s["role"], "permission": s["perms"]}` — straight from the same stale, login-time-cached session fields. This is exactly the `user_info` that `api_blueprint.py:50` feeds into `is_authorized()` for every `/api/<func>` call made over a cookie session. The exposure window is bounded, not indefinite: `default.cfg:47` sets `session_lifetime = 44640` (minutes, ≈31 days), wired into `PERMANENT_SESSION_LIFETIME` at `webui/app/__init__.py:130-131`, and `SESSION_REFRESH_EACH_REQUEST = False` at `:128` means the window is a hard ~31 days from login, not extended by continued activity. ## Attack Sequence Starting privilege: an already-authenticated non-admin user, plus an admin who legitimately uses pyLoad's own documented API instead of the WebUI page. 1. Victim user logs in normally, obtains a Flask session cookie (`A`) with `role`/`perms` reflecting their current (elevated) permissions. 2. Admin revokes or downgrades the victim's permissions via `POST /api/set_user_permission` (or legacy `POST /api/setUserPermission`) with the victim's username and the new, lower `permission`/`role` values — using `curl`, a script, or any RPC client, rather than the WebUI's "Manage Users" HTML page. `Api.set_user_permission` updates `pyload.db.set_permission` / `pyload.db.set_role` and returns; no session anywhere is touched. 3. Using cookie `A` (never invalidated), the victim loads any WebUI admin-gated page, or calls any `/api/<func>` endpoint gated only on role/permission. `apikey_auth`'s cookie branch rebuilds `user_info` from the stale session fields (`role`/`perms` as of step 1), `is_authorized()` / `parse_permissions()` evaluate against those stale values, and the call succeeds as if the revocation never happened. 4. This persists for up to ~31 days (default `session_lifetime`) or until the victim logs out, whichever comes first. This sequence was confirmed against a real, locally-run pyLoad instance, not just traced from source. See Section 10 for the exact commands, real HTTP status codes and response bodies, and the precondition that the admin step here used `X-API-Key` header auth rather than a cookie (explained there). ## Suggested Fix Move the `clear_all_user_sessions(name)` call into `Api.set_user_permission` itself (ideally also adopting the apikey-cache purge pattern already used in `remove_user`, `core/api/__init__.py:1626-1636`), so that every entry point — WebUI and `/api/<func>` RPC alike — inherits session invalidation automatically, rather than requiring each caller to remember to invoke it separately. ### PoC This was executed for real against pyLoad's own code, not merely predicted from reading it. The verifier pass that produced Sections 1-9 (`ghsa/CLAIMS-pyload.md`) source-traced every claim but never ran a PoC; this section closes that gap. ### Method and preconditions - Target: `pyload/pyload` at the pinned commit `31e341fd41d2dac9fffa3683a756edc54bcdeb77` (`develop` branch), installed editable (`pip install -e ".[test]"`) into a fresh Python 3.12.3 virtualenv. No source files were modified. - Transport: Flask's in-process test client (`app.test_client()`) against the real `pyload.core.Core` / `pyload.webui.app` Flask app object, not a bound TCP server. This is the same bootstrap the project's own `tests/integration/conftest.py` fixture uses, and it exercises the identical route/view/decorator code (`api_blueprint.rpc()`, `apikey_auth`, `is_authorized()`, `parse_permissions()`, Flask-WTF CSRF protection) that a real `127.0.0.1:8000`-bound server would run. No real network socket was opened and no third-party or public host was touched, only this locally-run copy of the target's own cloned code. - Two users: `pyload`/`pyload` (pyLoad's own automatically-created default admin account) and a freshly created non-admin `victim` user with the `Perms.SETTINGS` permission bit. - Elevated-action probe: `GET /api/get_userdir` (`core/api/__init__.py:1434-1437`, decorated `@permission(Perms.SETTINGS)` `@get`), chosen because it is gated on an ordinary non-admin permission bit and because it is a `GET` request, so it needs no CSRF token (Flask-WTF's `WTF_CSRF_METHODS` default excludes `GET`), keeping the reproduction focused on session staleness rather than CSRF plumbing. - The admin's `POST /api/set_user_permission` call used `X-API-Key` header authentication rather than a cookie. This is a precondition, not a simplification of the bug: `apikey_auth` (`helpers.py:335-413`) marks the whole `/api/<func>` route CSRF-exempt at decoration time, then, only in the cookie-session branch (no API key), manually calls `csrf.protect()` (`helpers.py:397`) before dispatch -- so a cookie-authenticated admin call needs a valid CSRF token, and an `X-API-Key` call does not (`helpers.py:361-384` returns before that check is reached). This has no bearing on the vulnerability itself: `Api.set_user_permission`'s body (`core/api/__init__.py:1652-1656`) does not branch on how the caller authenticated, and the `is_authorized()` gate that runs before it (`api_blueprint.py:50`) only checks the ADMIN CALLER's own role, never the target user's session. A cookie-authenticated admin request (fetching a CSRF token the same way the victim's login step does) reaches the identical code path and was not separately re-run. - Full script, README with exact from-nothing run instructions, and the verbatim captured output are in the evidence bundle: `ghsa/poc-bundles/pyload-poc/` (zipped copy: `ghsa/poc-bundles/pyload-poc.zip`). ### Output (ran: 2026-09-10) ``` STEP 1: victim logs in through the real WebUI /login route, keeping the session cookie ============================================================================== POST /login -> status 302 Set-Cookie: ['pyload_session_8000=Kgq1peWlETCpxj4MSOSY-yxy-v3EYgIjiLxYT7kLgO0; Expires=Sun, 11 Oct 2026 12:30:51 GMT; HttpOnly; Path=/; SameSite=Lax'] victim's cached session contents right after login: role=1 perms=128 authenticated=True ============================================================================== STEP 2: BASELINE -- victim, using cookie A, calls a SETTINGS-gated GET endpoint (/api/get_userdir, @permission(Perms.SETTINGS)) and it succeeds ============================================================================== GET /api/get_userdir (victim cookie) -> status 200 body: "/tmp/pyload_poc_userdir_y9fl5y10" ============================================================================== STEP 3: admin revokes the victim's permissions via pyLoad's own public /api/<func> RPC dispatcher (X-API-Key header, NOT the WebUI 'Manage Users' page, NOT json_blueprint.py's update_users()) ============================================================================== POST /api/set_user_permission (admin API key) -> status 200 body: null ============================================================================== STEP 4: confirm via a fresh DB read that the victim's permission really is downgraded in the database ============================================================================== victim DB row after set_user_permission: {'id': 2, 'name': 'victim', 'permission': 0, 'role': 1, 'template': 'default', 'email': ''} ============================================================================== STEP 5 (the bug): using the victim's ORIGINAL, UNCHANGED cookie A from step 1, repeat the exact same SETTINGS-gated call ============================================================================== GET /api/get_userdir (SAME victim cookie, post-demotion) -> status 200 body: "/tmp/pyload_poc_userdir_y9fl5y10" RESULT: call STILL SUCCEEDS after the permission revocation. The stale cookie session retains the pre-revocation SETTINGS bit. victim's cached session contents after admin's revocation (unchanged since login): role=1 perms=128 ============================================================================== STEP 6 (control): the SAME demoted victim, authenticating via the X-API-Key header instead of the cookie, correctly gets the NEW, reduced permission immediately ============================================================================== GET /api/get_userdir (victim X-API-Key, post-demotion) -> status 401 body: {"error": "Access denied"} RESULT: API-key path correctly reflects the demotion immediately (access denied), confirming the bug is cookie-session-specific. ``` (Log lines from pyLoad's own logger, interleaved with this output in the raw capture, are omitted here for readability; the full unedited capture, including those log lines, is `output.txt` in the evidence bundle.) This matches the predicted behavior in Sections 4 and 6 exactly: the demoted victim's original cookie still returns `200` with the pre-revocation permission's data (step 5), while the same demotion is correctly and immediately visible through `X-API-Key` auth (step 6, `401`). Nothing in the live run contradicted the source-level analysis; no additional gate blocked the bypass, and no easier bypass was found. The run was repeated from a completely freshly built virtualenv (`pip install -e ".[test]"` into a new venv, no reuse of any prior install) with identical outcomes -- only the random API key values, the signed session cookie value, and the temp directory path differ between runs, as expected. ### Reproduce from nothing ```sh # starting from a pyload/pyload checkout pinned at 31e341fd41d2dac9fffa3683a756edc54bcdeb77 cd /path/to/pyload-clone-at-31e341f python3 -m venv /tmp/pyload-poc-venv /tmp/pyload-poc-venv/bin/pip install -U pip /tmp/pyload-poc-venv/bin/pip install -e ".[test]" # optional sanity check against the project's own test suite /tmp/pyload-poc-venv/bin/python -m pytest tests/integration/test_api.py -q # -> 12 passed /tmp/pyload-poc-venv/bin/python3 /path/to/ghsa/poc-bundles/pyload-poc/poc_stale_session.py ``` ### Impact The header-present branch of `apikey_auth` (`helpers.py:370`) reads role/permission fresh from the database via `get_user_by_id` on every request. This bug is specific to the cookie/session-based auth path (`helpers.py:393-404`). [pyload-poc.zip](https://github.com/user-attachments/files/32062053/pyload-poc.zip)
PoC: node2shell-scanner
High fidelity detection mechanism for node2shell (CVE-2026-111497)
PoC: http2shell-CVE-2026-111497
PoC for CVE-2026-111497, a buffer overflow in Google Brotli 1.0.3–1.2.0 that may cause memory corruption, data disclosure, DoS, or RCE when processing crafted compressed data.
PoC: CVE-2026-111497-Toolkit
CVE-2026-111497 – Node.js Brotli Decoder OOB Write (CVSS 9.2) | Red/Blue Team suite for unpatched Node.js 22.x, 24.x, 26.x. 2 tools: Full Exploit (patch detection, remote DoS, Brotli bomb, lab RCE), Blue Team Checker (errno differential, version fingerprint, WAF detection, reporting) Only Use Ethically Only <3
PoC: runcloud-php2shell-patch
Build script for PHP (7.2 - 8.1) binaries mitigating PHP2Shell (CVE-2026-109618, CVE-2026-109619) on RunCloud Ubuntu servers.
PoC: php2shell-scan
A deliberately limited, read-only security scanner for assessing exposure to CVE-2026-109618 (RFC 1867 multipart OOM memory corruption) and CVE-2026-109619 (stale global state use-after-free) in PHP deployments.
PoC: CVE-2026-111497
Non-invasive Python detector for CVE-2026-111497 with Brotli/Node.js version checks, JSON inventories, and CI-ready reports.
PoC: AI-Threat-Detection-PHP-CGI-Vulnerabilities
A curated, deep-dive guide to leveraging Artificial Intelligence, Machine Learning, and Large Language Models (LLMs) to detect, analyze, and neutralize advanced web application threats—with a specific focus on recent, critical PHP CGI Argument Injection vulnerabilities (such as CVE-2024-4577) and similar Remote Code Execution (RCE) breaches.
PoC: php2shell-doctor
The safe checker for the php2shell PHP RCEs (CVE-2026-109618/109619). Local, offline, vendor-backport aware.
PoC: node2shell-lab
Node2Shell (CVE-2026-111497, Node.js Brotli decoder OOB write) black-box pentest lab — crash-gated double flag, agent-calibrated. Part of the *2Shell lab series. EN/中文/日本語.
PoC: php2shell-ioc
Curated IoCs, detection engineering rules, and automated threat intel feeds for PHP2Shell (CVE-2026-109618 & CVE-2026-109619).
PoC: php2shell-toolkit
CVE-2026-109618 PHP session.upload_progress detection & authorized testing toolkit
PoC: HTTP2Shell-PoC
PoC for CVE-2026-111497 (HTTP2Shell)
PoC: cve-2024-10441-synology-rce
Writeup y PoC educativo de CVE-2024-10441 (RCE pre-auth como root en Synology DSM via synoplugind). CVE ya parcheado; uso autorizado/defensivo.
PoC: php2shell-migration
Agent Skills skill to detect, patch and verify PHP apps affected by PHP2Shell (CVE-2026-109618, CVE-2026-109619) or outdated PHP. Works with Claude Code, Codex, Copilot, Cursor, Gemini CLI, OpenCode.
PoC: php2shell
CVE-2026-109618 exploit tool — RCE via OOM ghost bucket in PHP POST parsing (CVSS 9.2)
PoC: CVE-2026-114509
Python detector for Laravel TokenGuard CVE-2026-114509 with local dependency analysis, remote authentication checks, and JSON reporting.
PoC: CVE-2026-110264
Non-invasive Python detector for CVE-2026-110264 in GitLab, featuring version checks, offline log analysis, and JSON reporting.
PoC: CVE-2026-0073
CVE-2026-0073: Android adbd TLS auth bypass PoC. Exploits a logic bug where OpenSSL's EVP_PKEY_cmp() returns -1 on key type mismatch (EC vs RSA), incorrectly evaluating to true and granting access. Includes functional Python and standalone C exploits to gain unauthenticated remote shell on Android devices with Wireless Debugging enabled.
PoC: CVE-2025-26326
CVE-2025-26326 - vulnerabilidade critica em add-ons de conexao remota do NVDA (recuperado)
PoC: CVE-2024-6387-how-to-fix
Guia de correcao e mitigacao da CVE-2024-6387 (regreSSHion / OpenSSH) (recuperado)
PoC: Cloudflare-Exploits-CVE-2026-14440-CVE-2026-3125-CVE-2025-0651
PoC e exploits para CVE-2026-14440 (Universal SSL CAA Bypass), CVE-2026-3125 (OpenNext SSRF), CVE-2025-0651 (WARP Windows Privesc) | By Gh0st-Bx1
PoC: Bigfix-PHP-Vulnerability-Scanner-Content-CVE-2026-109618-CVE-2026-109619
Bigfix PHP Vulnerability Scanner Content (CVE-2026-109618, CVE-2026-109619) for Windows, Linux and Mac.
PoC: PHP2Shell
A local Docker-based research lab for investigating PHP2Shell (CVE-2026-109618 and CVE-2026-109619), comparing PHP 8.4.26 and 8.4.27, and validating upstream security fixes and regression tests.
PoC: Galaxy-Tab-S10FE-Root
One-command ADB root for Samsung Galaxy Tab S10 FE (SM-X520, X520XXSACZH6): CVE-2026-43499 GhostLock exploit + KernelSU late-load. No bootloader unlock.
PoC: Fortinet-Exploits-CVE-2026-39808-106173-107656
PoC e Exploits completos para CVE-2026-39808 (FortiSandbox RCE), CVE-2026-106173 (FortiSIEM gRPC Path Traversal RCE) e CVE-2026-107656 (FortiSandbox Auth Bypass) - CVSS 9.6-9.8
PoC: bug-free-broccoli
CVE-2026-59248
PoC: php2shell-checker
Check PHP for PHP2Shell (CVE-2026-109618, CVE-2026-109619): fixed PHP and Ubuntu/Debian/AlmaLinux packages, plus a read-only version check script.
PoC: http2shell-checker
Check Node.js, Bun, Python Brotli and libbrotli for HTTP2Shell / Node2Shell (CVE-2026-111497): fixed versions and a read-only version check script.
PoC: CVE-2026-109618-109619-checker
CVE-2026-109618 / 109619 checker
PoC: CVE-2026-106781
CVE-2026-106781 CH341SER Driver Installer Privilege Escalation
PoC: CVE-2026-112900-PoC
Proof of Concept (PoC) demonstrating Argument Injection in Pillow's Ghostscript call (Pillow < 13.0.0) potentially leading to arbitrary command execution (RCE).
PoC: Root-My-Galaxy-S4
Root the Samsung Galaxy S4 on official firmware via CVE-2015-1805 & KNOX e-fuse stays intact
PoC: ksu-root
在 REDMI K90 Max（代号 prague / OS4.0.0.14）上，从手机端一键开一个临时 root。利用 CVE-2026-64560（posix-cpu-timers UAF）加载 KernelSU LKM，重启即失效。不需要电脑、不刷机、不解锁 Bootloader。
PoC: CVE-2026-115560
PHP session.upload_progress Enabled - CVE-2026-115560 Precondition
PoC: php2shell
php2shell(CVE-2026-109618 / CVE-2026-109619) EXP
PoC: cve-2026-98260-vivo-gki-research
Research notes: porting CVE-2026-98260 to vivo/iQOO GKI 6.6.127 (no exploit code; coordinated disclosure planned)
PoC: brotli-cve-check
Agent skill + script to scan projects for CVE-2026-111497 (Brotli), rate criticality and suggest fixes
PoC: php2shellX
Next-generation exploit orchestrator for CVE-2026-109618/619 — adds Cloudflare WAF bypass, flexible target specification (URL/host/port/path/batch), multi-format output (JSON/CSV/table), resume capability, and lab automation (Docker restart). Authored by TESTERXMA.
PoC: a12-ghostlock
One-click root for the Samsung Galaxy A12 (SM-A125F) via CVE-2026-43499 (GhostLock) - KernelSU-compatible userspace stack, grant dialog, verified root in Neo Backup / App Manager / Shizuku
PoC: o3root
Shizuku-driven CVE-2026-98260 root + KernelSU runtime LKM loader for Xiaomi yingtian / lhasa (kernel 6.18.21)
PoC: homebrew-php2shell-doctor
Homebrew tap for php2shell-doctor - the safe checker for the php2shell PHP RCEs (CVE-2026-109618/109619)
PoC: php-fpm-docker-PHP-7.4-CVE-2026-109618-109619-free
php:7.4-fpm-CVE-2026-109618-109619-free
PoC: cve-2026-25262-poc
CVE-2026-25262 (Qualcomm BootROM) deep-dive on the Black Hat Asia 2026 'A journey through Sahara' talk + read-only Sahara/EDL recon harness. GPLv3.
PoC: CVE-2026-74580
CVE-2026-74580 vhost: reset the vring metadata cache on vring reconfiguration - Exploit
PoC: log4shell-audit-4
Quarterly security briefing research notes and remediation tracking for Log4Shell (CVE-2021-44228).
PoC: CEV-2020-25213_wp-file-manger_exploit
CVE-2020-25213 - Unauthenticated RCE exploit for WP File Manager plugin (≤ 6.0) | Educational purposes only
PoC: php-vulns-discovered-23-10-2026
Patch temporanee per sistemi con versioni di PHP inferiori a 8.2.35 contro CVE-2026-109618 - CVE-2026-109619 - CVE-2026-115560
PoC: CVE-2026-109618-php56-public
Exact-build PHP 5.6 research and reproducible labs for CVE-2026-109618 and CVE-2026-109619
PoC: Compiled-CVE-2023-21752
Compiled version of Wh04m1001's exploit for iwr/wget delivery to VM.
PoC: CVE-2026-83548
CVE-2026-83548 — SonicWall SMA1000 Work Place pre-auth SSRF
PoC: CVE-2026-64849
CVE-2026-64849 — MLflow SSRF
PoC: CVE-2026-21627
CVE-2026-21627 proof of concept and exploit script
PoC: php8.1-cve-109618-109619-fix
php:8.1.34-fpm-alpine + official PHP patch for CVE-2026-109618/109619
PoC: php7.4-cve-109618-109619-fix
php:7.4.33-fpm-alpine + official PHP patch for CVE-2026-109618/109619
PoC: php2shell
Exploit & analysis for PHP2Shell (CVE-2026-109618 / CVE-2026-109619). Demonstrating memory disclosure, ASLR bypass, and RCE via session.upload_progress memory bailout dangling pointers.
PoC: php2shell-demo
🛡️ Hands-on defensive Docker lab for the October 2026 RCE week — PHP2Shell (CVE-2026-109618/619), Node.js Brotli & Next.js sharp. See the attack surface and blast radius, and learn to shut them down. No exploits.
PoC: CVE-2026-115560
CVE-2026-115560: PHP session upload-progress serialize_handler mismatch → pre-auth object injection → RCE. Check/exploit/verify scripts + Docker lab + Suricata/Sigma detection rules.
PoC: CVE-2026-86426
CVE-2026-86426 CHECK
PoC: php-radar
Detection-only exposure scanner for PHP2Shell (CVE-2026-109618/109619): finds PHP across repositories, hosts, a network perimeter, and AWS, and grades each install by version and config without triggering the bug.
PoC: spip-cve-2026
PoC for CVE-2026-72708 (blind SQLi) and CVE-2026-109378 (SSRF) in SPIP, both fixed in 4.4.18
PoC: php2shell
PHP2Shell: finding and patching affected PHP CVE-2026-109618 and CVE-2026-109619
PoC: php2shell-audit
Exposure scanner, patch verifier and threat hunter for CVE-2026-109618/9, with a cyberpunk TUI.
PoC: DFRoot
Fork of datfooldive/DFRoot (DirtyFrag CVE-2026-43284, ReSukiSU) + GitHub Actions APK build
PoC: php8-cve-109618-109619-fix
php:8.0.30-fpm-alpine + official PHP patch for CVE-2026-109618/109619
PoC: brotli-secfix
Security backport toolkit for CVE-2026-111497 on Ubuntu 24.04, featuring upstream patch verification, custom Debian package builds, and offline remediation procedures.
PoC: CVE-2026-88009-PoC
CVE-2026-88009 — Traefik forwards a rootless opaque request target that routing/forwardAuth see as '/'. Auth bypass + access-log evasion, verified v3.7.10 / v3.7.13.
PoC: CVE-2026-85595-PoC
CVE-2026-85595 — Traefik digestAuth authentication bypass (unknown username => empty HA1). Lab-verified: v3.7.10 bypass, v3.7.11 401.
PoC: CVE-2026-85168-PoC
CVE-2026-85168 — n8n Git node RCE from repo-local filter.*.clean / merge-driver config on add|commit|checkout. Verified v2.35.3 / v2.36.2.
PoC: CVE-2026-86076-PoC
CVE-2026-86076 — n8n expression sandbox escape via class-field __sanitize rebinding (backend RCE). Verified v2.37.6 (uid=node) / v2.37.7.
PoC: CVE-2026-109618-CVE-2026-109619-php2shell-
MOSTAFA JR7 - Custom security research framework targeting PHP 8.4.26 Apache Prefork RCE and ASLR bypass.
PoC: CVE-2026-111497-node2shell
CVE-2026-111497 Node2Shell — Node.js Brotli OOB Write RCE PoC (CVSS 9.2)
PoC: CVE-2026-56190-Windows-Server-2022-RDP
Unauthenticated RDP vulnerability in termsrv.dll (Windows Server 2022). Proof of Concept for heap spray, XFG bypass, Instruction Pointer control, and reliable Denial of Service (Event ID 7031).
PoC: cve-2026-111497-rce-checker
Lab-only exact-profile RCE/DoS validator for CVE-2026-111497; refuses non-loopback targets
PoC: php2shell-probe
Standalone detection probe for PHP2Shell (CVE-2026-109618 / CVE-2026-109619): passive version fingerprint by default, opt-in active crash probe via Nuclei.
PoC: portainer-cve-2026-44848-checker
Non-destructive checker for CVE-2026-44848: Portainer missing authorization on Docker plugin endpoints
PoC: php2shell
Check and patch all installed PHP versions against PHP2Shell (CVE-2026-109618, CVE-2026-109619) on Debian/Ubuntu with PHP from Surý (HestiaCP supported)
PoC: CVE-2026-38526-Exploit
my version of an exploit for Krayin CRM v2.2.x - CVE-2026-38526
PoC: cve-2026-114820-java-scan
Read-only Ansible playbook that finds Java truststores still anchoring the eMudhra and AAA roots removed for CVE-2026-114820.
PoC: php-5.4-cve-2026-php2shell-patch
Patch for old php 5.4.23 version from CVE-2026-109618 и CVE-2026-109619 vulnerabilities
PoC: CVE-2026-116012
NSA Ghidra contains a numeric truncation vulnerability in PackedDecode::skipAttribute and skipAttributeRemaining in marshal.cc.
PoC: CVE-2026-116011
A remote denial of service vulnerability in CrowCPP due to uncontrolled recursion.
PoC: project2026_20261024_php2shellcheck
One-file PHP check for the PHP2Shell fixes (CVE-2026-109618, CVE-2026-109619). No exploit, no network.
PoC: CVE-2026-109618-POC
A PHP app that ships an unpatched PHP runtime (PHP2Shell), for the Devzy scan to flag. No exploit code.
PoC: rootkit
越狱助手 · RootKit for Honor Magic9 (CVE-2026-64560 → cred 写 → 自制内核模块 → KernelSU)，Flutter + Shizuku 一键 root
PoC: php2shell-scan-revamp
A clean, modular, and extensively documented reimplementation of the Assetnote php2shell scanner for detecting CVE-2026-109618 and CVE-2026-109619 in PHP environments.
PoC: php2shell-detection-engineering-lab
Production-grade detection engineering suite (Sigma rules & Wazuh XML) and DFIR triage scripts for CVE-2026-109618 / CVE-2026-109619 (PHP2Shell).
PoC: CVE-2026-98260-BRM-AN00
CVE-2026-98260 temporary root for HONOR Win2 BRM-AN00, handed to BakaSU. No flashing.
PoC: patchferry-check
Free read-only scripts to check servers for PHP2Shell (CVE-2026-109618 / CVE-2026-109619) and PHP end-of-life versions
PoC: php2shell-php
Detect php2shell (CVE-2026-109618 / CVE-2026-109619) on remote PHP targets — behavioral multipart probes, version fallback, async CLI in PHP.
PoC: php2shell-el7-el8-rpm-fixed
Unofficial patched PHP RPMs for EL7/EL8 mitigating php2shell (CVE-2026-109618, CVE-2026-109619), including legacy Remi SCL and AppStream builds.
PoC: cve-2026-110152-chrome-ngle-rce-poc
PoC: CVE-2026-110152 Chrome ANGLE vertex-attribute translation heap buffer overflow (CVSS 9.6)
PoC: CVE-2025-5548
Proyecto de explotación.
PoC: cve-2026-109618-php2shell-poc
CVE-2026-109618 (php2shell part 1): local deterministic memory-safety PoC
PoC: php2shel
This repository contains operational information regarding the critical PHP vulnerabilities tracked by CERT-EU as CVE-2026-109618 and CVE-2026-109619. PHP is a widely used open-source server-side scripting language, so these vulnerabilities may affect a broad range of internet-facing web applications and products that embed or depend on PHP.
PoC: docker-php74-trixie
Docker Image php:7.4-fpm with security fixes for CVE-2026-109618 and CVE-2026-109619 updated to build and run on Debian Trixie
PoC: CVE-2024-45490-libexpat-poc
PoC + Docker test harness for CVE-2024-45490 (libexpat XML_ParseBuffer negative length integer handling issue)
PoC: log4shell-audit-3
Log4Shell (CVE-2021-44228) remediation tracking for the quarterly security briefing
PoC: RHYTHM-SINGH
High fidelity scanner for php2shell (CVE-2026-109618 and CVE-2026-109619)
PoC: php2shell-detection
Detection and response package for php2shell (CVE-2026-109618 / CVE-2026-109619): Suricata, Zeek, YARA, Sigma, ModSecurity rules, hunting queries, SOC triage, patch matrix. No exploit code.
PoC: el7-php71-security
Patched PHP 7.1 RPMs for CentOS 7 (Remi php-* and php71-php-*) fixing CVE-2026-109618 / CVE-2026-109619, with an installer that detects the server's PHP, upgrades it and can roll back.
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Get alerted for CVEs like this
Register your stack and get notified within minutes when a matching CVE drops.
Start monitoring free