You didn't ship bad code this week. You could still be hacked.

You are a security engineer on my team. Between 14 and 21 October 2026, five critical supply-chain issues were disclosed. Find every place this repository and this machine are exposed, fix what you can, and tell me exactly what is left.

## Ground rules
- First create a git branch: security/oct-2026-advisories. Never commit to main.
- You MAY change code and config yourself: dependency versions, lockfiles, Dockerfiles, compose/k8s/Helm files, CI files.
- After each fix, reinstall dependencies and run the project's existing build and tests. If they break, fix them or roll back that change and tell me why.
- STOP AND ASK me before: running anything against production, upgrading packages on a live server, restarting services, deleting files, or rotating/revoking any credential.
- NEVER print secret values. When you list secrets, list names and locations only.
- If you cannot verify something, mark it UNSURE. Do not guess.

## Step 1 — Detect (do all five before fixing anything)

1. NEXT.JS image RCE — CVE-2026-96889 (also fixes a `use cache` RCE and a Server Actions DoS)
   - Every package.json + lockfile: resolved versions of `next` and `sharp`.
   - Vulnerable: next 10.0.0–15.5.27 or 16.0.0–16.4.0, or sharp < 0.35.5.
   - Note if next.config uses `dangerouslyAllowSVG` or code uses `next/og` ImageResponse (highest exposure).

2. eMUDHRA weak CA keys — root "emSign ECC Root CA - G3" (Chrome distrusts it on 27 Oct 2026)
   - Grep the repo for "emSign" in PEM files, CA bundles, trust stores, configs.
   - Python `certifi` version (need >= 2026.10.19). Base images and their ca-certificates update step.
   - Collect every domain the app serves or calls. If network is available, run:
     echo | openssl s_client -connect DOMAIN:443 -showcerts 2>/dev/null | grep -i emsign

3. LITELLM malicious release 1.107.0 — credential stealer that runs on every Python start
   - requirements*.txt, pyproject.toml, poetry.lock, uv.lock, Pipfile.lock, Dockerfiles, compose, k8s: any `litellm` that is ==1.107.0, unpinned, or a range that allowed 1.107.0 on 21 Oct.
   - Images litellm/litellm or ghcr.io/berriai/litellm* tagged v1.107.0, latest, main-latest or main-stable.
   - On THIS machine, across every Python env you can find: `pip show litellm`; files named cook.pth or cook.py in site-packages; the marker file /tmp/.pc_once_72129118c59f5636c0bb; shell history or logs mentioning litellm.dev (the real domain is litellm.ai).

4. GITLAB self-managed, CVSS 10 — CVE-2026-110264 (patching on 12 Oct is NOT enough)
   - Find self-hosted GitLab references: compose/k8s/Helm using gitlab/gitlab-ce or gitlab-ee, CI runner configs, git remotes.
   - If you can read the version (e.g. /opt/gitlab/embedded/service/gitlab-rails/VERSION), compare with fixed releases: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13.

5. PHP core RCE — CVE-2026-109618, CVE-2026-109619 (public exploits exist)
   - Dockerfiles with php images, composer.json, .php-version, `php -v` on this host.
   - Fixed: 8.5.12, 8.4.27, 8.3.36, 8.2.35.

Print a table: Issue | Exposed? (YES / NO / UNSURE) | Evidence (file:line or command output).

## !! If you find ANY LiteLLM infection indicator on this machine
Stop all other work. Tell me immediately in plain words: this machine must be treated as compromised and isolated. Then build a rotation list (names and locations only, never values) of every secret this machine could reach: env var names, .env files, ~/.aws, ~/.config/gcloud, ~/.azure, ~/.kube, ~/.ssh, ~/.docker, ~/.npmrc, ~/.pypirc, gh CLI auth, CI secrets referenced in workflow files, LLM provider keys, and keys stored in any LiteLLM proxy database. Then wait for me.

## Step 2 — Fix

1. Next.js
   - Same major: install next@16.4.1 (v16) or next@15.5.28 (v15) with the project's package manager.
   - Force sharp >= 0.35.5 everywhere: npm "overrides", pnpm "pnpm.overrides", yarn "resolutions". On v15 this is required; 15.5.28 still accepts the vulnerable sharp 0.34.
   - Regenerate the lockfile, confirm every resolved sharp is >= 0.35.5, then build.
   - On next < 15: do not attempt a major upgrade unasked. Apply the sharp override, and tell me the app still needs a major upgrade.

2. eMudhra
   - Remove any vendored "emSign ECC Root CA - G3" certificate from bundles in the repo.
   - Pin certifi >= 2026.10.19. Make every Dockerfile update ca-certificates (or bump the base image).
   - If a domain we own chains to that root, tell me: replace the certificate from another CA before 27 Oct 2026. You cannot do this part.

3. LiteLLM
   - Pin litellm==1.106.2 everywhere. Replace floating image tags with v1.106.2, by digest if you can resolve it.
   - Rebuild and run tests.

4. GitLab
   - If its version is in a file in this repo (compose, Helm values), bump to the fixed release for that line.
   - If it runs on a host, show me the exact upgrade command for its install type and wait for my go-ahead.

5. PHP
   - Bump php image tags in Dockerfiles to the patched release of the same minor (e.g. 8.4.27).
   - For hosts or managed hosting, give me the command or the exact sentence to send my hosting provider.

## Step 3 — Make the next one faster to catch
Propose (as a diff, do not apply until I say yes):
- A CI job that fails on known-vulnerable or known-malicious packages (osv-scanner, npm audit, or pip-audit).
- Exact version pins and committed lockfiles where they're missing; no floating Docker tags.
- Dependabot or Renovate config if none exists.

## Step 4 — Hand back
- Commit the fixes on the branch: "security: remediate Oct 2026 advisories (Next.js, eMudhra, LiteLLM, GitLab, PHP)".
- Write SECURITY-REMEDIATION.md with:
  1. Final table: Issue | Was exposed? | What you changed | Verified how
  2. NEEDS A HUMAN: everything you could not do, who should do it, and the deadline (eMudhra: before 27 Oct).
  3. One honest paragraph: if a trusted dependency turned malicious tomorrow, what in this setup would alert us, and how fast?
- Show me the summary and the diff stat. Do not push or open a PR until I confirm.