Abhängigkeiten auf Sicherheits-Updates prüfen und Versionen verbindlich machen #11
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem
Die Abhängigkeiten wurden noch nie systematisch auf bekannte Schwachstellen geprüft, und es gibt keine Stelle im Projekt, die das automatisch tut (
scripts/publish.sh::run_local_checks()ersetzt seit dem Wegfall der Forgejo-Actions die CI, prüft aber nur ruff/pytest/tsc/eslint/vitest/build — keinnpm audit, keinpip-audit).Eine Prüfung am 17.09.2026 (npm audit + OSV-Datenbank) hat 6 Advisories im Frontend, veraltete Basis-Images und eine strukturelle Lücke bei der Versionsbindung im Backend ergeben. Details unten, jeweils mit Bewertung, ob PatchPilot tatsächlich betroffen ist.
Befunde
1. Frontend:
react-router-dom6.30.4 — wird an den Browser ausgeliefert<Link>/useNavigatedeserializeErrors()(SSR-Hydration)Zur Ausnutzbarkeit:
useNavigate()wird nur mit fest verdrahteten Zielen aufgerufen (frontend/src/App.tsx:51→/login,frontend/src/pages/Login.tsx:22→/), es gibt kein<Link to={…}>mit Fremddaten. Die beiden Open-Redirect-Advisories sind damit aktuell nicht auslösbar — das kann sich aber mit jeder neuen Route ändern.Der 6.x-Zweig bekommt für GHSA-wrjc und GHSA-337j keinen Fix mehr. Hier ist eine bewusste Entscheidung nötig: bei 6.30.6 bleiben und die beiden als nicht-ausnutzbar dokumentieren, oder auf react-router 7 migrieren (Breaking Change).
2. Frontend: Build-/Testwerkzeuge (laufen nicht im ausgelieferten Bundle)
viteserver.fs.deny-Bypass, dazu GHSA-4w7w-66w2-5vf9 und GHSA-v6wh-96g9-6wx3esbuildvitest@vitest/mockerDiese Pakete landen nicht im Produktions-Bundle — betroffen ist der Entwicklungsrechner, solange
npm run devläuft (der Dev-Server ist über das Netz erreichbar). Beide Upgrades sind Major-Sprünge (vite 5 → 6, vitest 3 → 4) und brauchen einen Testlauf, keinnpm audit fix --forceauf gut Glück.3. Backend:
requirements.txtohne VersionsbindungAlle zehn Einträge stehen als
>=Xohne Obergrenze, es gibt keine Lock-Datei. Ein heute aufgelöster Build ergibt 36 Pakete — davon hat aktuell keines eine bekannte Schwachstelle (gegen OSV geprüft). Das ist aber Zufall und kein Zustand:Nicht reproduzierbar: zwei Builds am selben Commit können unterschiedliche Versionen enthalten. Welche Version im laufenden Container steckt, lässt sich aus dem Repo nicht ablesen.
Ein gebautes Image altert still: es behält seine Versionen, bis jemand neu baut. Genau das zeigt das lokale
.venvdieses Projekts — dort stecken noch:starlette1.2.1 → CVE-2026-54283 (high, DoS:request.form()-Limits werden ignoriert) und CVE-2026-54282. Behoben in 1.3.1; ein frischer Build zieht 1.6.0.cryptography48.0.0 → vier Advisories, u.a. GHSA-537c-gmf6-5ccf (verwundbares OpenSSL in den Wheels) und CVE-2026-69247 (Bleichenbacher-Orakel in PKCS#7). Behoben in 50.0.0; ein frischer Build zieht 50.0.1. Relevant, weilcryptographyunterparamikodie SSH-Krypto stellt.Über die App selbst ist der Starlette-DoS nicht erreichbar (PatchPilot hat keinen einzigen Form- oder Upload-Endpunkt, geprüft per
grepaufrequest.form/UploadFile/Form(/File(), und diecryptography-Punkte betreffen X.509-Pfadprüfung bzw. PKCS#7, die PatchPilot nicht selbst aufruft. Der Punkt ist nicht die konkrete Ausnutzbarkeit, sondern dass das Projekt es nicht merken würde.4. Docker:
node:20-alpineist End-of-LifeDockerfileZeile 2 baut das Frontend auf Node 20 — EOL seit 2026-04-30, es gibt keine Sicherheitspatches mehr für dieses Image. Empfehlung:node:22-alpine(EOL 2027-04-30) odernode:24-alpine(EOL 2028-04-30).python:3.12-slim(Zeile 10) ist bis 2028-10-31 unterstützt und damit unkritisch; ein Wechsel auf 3.13 wäre optional. Beide Tags ohne Patch-Level sind hier richtig so — ein Rebuild holt die Patches automatisch.5. Nebenbefund: Altlasten im lokalen
.venvIm Entwicklungs-venv liegen Pakete, die weder in
requirements.txtstehen noch irgendwo im Code importiert werden (geprüft pergrep) — vermutlich Reste der früherenmatrix-nio-Bot-Implementierung, bevorbackend/bot.pyaufrequestsumgestellt wurde:aiohttp3.13.5 (28 Advisories!),matrix-nio,python-multipart,h2,python-socks,aiohttp_socks.Die kommen nicht ins Docker-Image (dort wird nur
requirements.txtinstalliert), verfälschen aber jedes lokale Audit und lassen die Lage schlimmer aussehen als sie ist.Was geändert werden muss
Sofort (bekannte Schwachstellen im ausgelieferten Code):
react-router-domauf 6.30.6 heben (npm update react-router-dom— Patch, kein Breaking Change),package-lock.jsonmit committenEntwicklungsumgebung:
viteauf ≥ 6.4.3 heben (bringtesbuild≥ 0.25.0 mit) — Major-Upgrade,npm run buildundnpm run devdanach prüfenvitestauf 4.1.11 heben — Major-Upgrade,npm testdanach prüfen.venvneu aufsetzen (rm -rf .venv && python3 -m venv .venv && .venv/bin/pip install -r requirements-dev.txt), damit dort nicht längerstarlette1.2.1,cryptography48.0.0 und diematrix-nio-Altlasten liegenStruktur (verhindert, dass das Problem wiederkommt):
requirements.txtauf exakte Versionen (==) umstellen und eine reproduzierbare Auflösung committen (pip freezeder Prod-Closure oderpip-compile/uv pip compileaus einerrequirements.in)run_local_checks()inscripts/publish.shum Audits ergänzen, da es kein CI gibt:pip-audit -r requirements.txtundnpm audit --audit-level=high(imfrontend/-Block)pip-auditinrequirements-dev.txtaufnehmenDocker:
node:20-alpine→node:22-alpine(oder 24) inDockerfileZeile 2, danach ein kompletterdocker buildals GegenprobeAkzeptanzkriterien
npm audit --audit-level=highimfrontend/meldet keine Treffer mehr (verbleibende moderate-Treffer sind im Repo begründet dokumentiert).pip-audit -r requirements.txtmeldet keine Treffer.scripts/publish.shbricht ab, wenn eines der beiden Audits anschlägt — ein Release kann nicht mehr unbemerkt mit einer bekannten Schwachstelle rausgehen.>=).