DEV Community: Abhinav Yadav

Always Set persist-credentials: false in actions/checkout

Abhinav Yadav — Fri, 30 Oct 2026 17:33:04 +0000

There's a default in actions/checkout\ that most teams never change — and that quietly leaves a GitHub token sitting in a readable file for every subsequent step in the job.

The fix is one line. The reasoning is worth understanding.

The Setting

- uses: actions/checkout@v4
  with:
    persist-credentials: false  # default is true
~~~

By default (\`persist-credentials: true\`), the checkout action writes a git credential config file containing your GitHub token to \`$RUNNER_TEMP\`. That file persists for the lifetime of the job.

## What the File Looks Like

The checkout action creates a file at \`$RUNNER_TEMP/git-credentials-<UUID>.config\`:

~~~ini
[http "https://github.com/"]
    extraheader = AUTHORIZATION: basic <Base64-encoded-string>
~~~

The Base64 string decodes to \`x-access-token:<GITHUB_TOKEN>\`. It's not encrypted. It's not write-protected. It sits in \`$RUNNER_TEMP\` for every step after checkout to read.

## How Easy It Is to Exploit

Any step in the same job — including actions from third-party repos — can extract the token with a shell one-liner:

~~~bash
GH_TOKEN=$(
  cat "$RUNNER_TEMP"/git-credentials-*.config \
    | awk 'NR==2 {print $5}' \
    | base64 --decode \
    | cut -d: -f2
)
echo "token: ${GH_TOKEN:0:10}..."
~~~

This doesn't require \`${{ github.token }}\` or \`${{ secrets.GITHUB_TOKEN }}\` to appear anywhere in the workflow. The token is already on disk.

> [!WARNING]
> If any action you use is compromised via a supply chain attack, or if your workflow is vulnerable to script injection through untrusted input, that action can silently exfiltrate your GitHub token via this file.

Setting \`persist-credentials: false\` makes the checkout action **delete the credentials file** after checkout completes. The file is gone before the next step runs.

## The Practical Risk

The most realistic threat vectors:

**1. Compromised third-party action:** You pin \`some-org/some-action@v2\`. The maintainer's account is compromised, a new patch release is pushed, and the action now exfiltrates credentials. If you reference by tag (not commit SHA), you get the new version automatically.

**2. Script injection via PR titles or branch names:** Workflows that echo \`${{ github.event.pull_request.title }}\` into a \`run:\` block are vulnerable. An attacker opens a PR with a crafted title that executes a shell command reading the credentials file.

The \`persist-credentials: false\` flag eliminates the file-based exfiltration path. It doesn't prevent all attacks, but it removes the easiest one.

## What If I Need Git Auth in Later Steps?

Setting \`persist-credentials: false\` means subsequent \`git pull\`, \`git push\`, or other authenticated operations will fail without credentials being re-established.

The clean solution is \`gh auth setup-git\`, which configures Git to use the GitHub CLI credential helper:

~~~yaml
- uses: actions/checkout@v4
  with:
    persist-credentials: false

- name: Set up git credentials via GH CLI
  run: gh auth setup-git
  env:
    GH_HOST: github.com

- name: Pull latest
  run: git pull origin main
  env:
    GH_TOKEN: ${{ github.token }}
~~~

This configures \`~/.gitconfig\` with:

~~~ini
[credential "https://github.com"]
    helper =
    helper = !/usr/bin/gh auth git-credential
~~~

The credential helper calls out to the GitHub CLI at auth time, which reads \`GH_TOKEN\` from the environment — **only when Git actually needs to authenticate**, and without writing the token to disk.

The token is scoped to the steps where \`GH_TOKEN\` is explicitly passed in \`env:\`. It's not sitting in a file readable by any arbitrary code in the job.

## Pinning Actions by Commit SHA

While hardening your checkout step, pin by full commit SHA rather than a mutable tag:

~~~yaml
# Mutable — tag can be force-pushed to point at new, malicious code
- uses: actions/checkout@v4

# Immutable — this exact commit is guaranteed
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
~~~

Combined with \`persist-credentials: false\`, this closes both the supply chain mutation vector and the credential-on-disk vector in one checkout block.

## Automated Detection

Human review will miss this. Use static analysis in CI:

**[zizmor](https://docs.zizmor.sh)** — Rust-based, runs as a GitHub Action:

~~~yaml
- uses: woodruffw/zizmor-action@v1
~~~

Output when \`persist-credentials\` is not set:

~~~plaintext
warning[artipacked]: credential persistence through GitHub Actions artifacts
 --> .github/workflows/build.yml:7:9
  |
7 |       - uses: actions/checkout@v4
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^ does not set persist-credentials: false
  |
  = note: this finding has an auto-fix
~~~

**[ghasec](https://github.com/koki-develop/ghasec)** and **[ghalint](https://github.com/suzuki-shunsuke/ghalint)** also catch this and surface it with rule references.

Running any of these in CI ensures the check doesn't rely on engineers remembering to apply it manually.

> [!TIP]
> There is an open PR in the \`actions/checkout\` repo to flip the default to \`false\`, but it has been stalled for years. Until the default changes, enforce it via linting.

## Checklist

- [ ] \`persist-credentials: false\` on all \`actions/checkout\` steps
- [ ] Actions pinned to full commit SHAs, not mutable tags
- [ ] \`gh auth setup-git\` pattern for workflows that need post-checkout git auth
- [ ] zizmor or ghasec running in CI to catch new workflows
- [ ] Minimal \`permissions:\` scope on each job (\`contents: read\` unless write is required)

The same lesson applies to AI tooling: a token that sits where other code can read it will eventually be read. See [stop giving AI agents your production keys](https://yadui.dev/blog/stop-giving-ai-agents-production-keys) and the [LiteLLM 1.107.0 incident response guide](https://yadui.dev/blog/litellm-1-107-0-incident-response-ai-gateways) for what that looks like in practice.


---

*Originally published at [yadui.dev](https://yadui.dev/blog/github-actions-persist-credentials-security) by Abhinav Yadav.*

Stop giving AI agents your production keys

Abhinav Yadav — Fri, 30 Oct 2026 17:32:27 +0000

What CERT-In reported

On 15 October 2026, CERT-In issued advisory CIAD-2026-0049, rated critical, titled "AI Agents as Attack Vectors". It describes two kinds of incident, and both come down to how AI agent credentials are exposed and scoped.

In the first, AI model providers voluntarily disclosed that their models, during research and evaluation on the internet, reached the live systems of Indian organizations. The advisory says the agents read business records, including personal data and confidential material, using credentials and connection settings exposed in application configuration and public code repositories, and through permissive cloud service roles. It states that the agents' actions exceeded their assigned tasks and that none of the affected organizations detected the access themselves.

In the second, CERT-In's own threat hunting found attackers using publicly available AI-based offensive-security frameworks in a financially motivated campaign. The advisory says agentic tooling compressed the time from initial access to impact from days to a few hours.

The advisory does not name the providers, models or organizations. The Hacker News coverage summarizes the same points and notes that CERT-In published no indicators of compromise.

The striking line is this: CERT-In calls the root weaknesses conventional. Exposed keys, dormant test APIs, plaintext payment keys, over-permissive cloud roles and internet-exposed admin interfaces. Agents found and used them faster and more thoroughly than people do.

Two sides of the same problem

The advisory is useful for any team that runs agents, because it covers both directions. Your exposed credentials can be found by someone else's agent. Your own agent, if it holds broad production credentials, can do the same damage when it is misdirected by prompt injection or simply overreaches. OWASP calls the second case Excessive Agency (LLM06:2025) and lists excessive permissions as one of its three root causes.

For organizations, CERT-In's recommendations include a specific section on governing internal agents: give each run a separate, short-lived identity with least privilege, enforce default-deny egress, and keep a tamper-resistant log of agent activity covering at minimum all actions that affect production systems and data. The rest of this post turns that into concrete steps.

Step 1: find the keys you already leaked

Start where the advisory starts. CERT-In asks organizations to audit source code, repository commit history, CI/CD variables, configuration files, client applications and cloud storage for exposed credentials, then rotate any exposed credential, purge it from history and verify the fix externally. It also asks that every commit and build be scanned for secrets.

On GitHub, secret scanning checks the full Git history of a repository for known secret formats, and push protection can block a commit containing a supported secret before it lands. Turn both on for every repository, not only public ones. CI is a common leak path too; see why persist-credentials in GitHub Actions matters. Remember the order: rotate first, then clean history. A deleted commit does not un-leak a key someone has already copied.

Step 2: replace stored secrets with workload identity

The most reliable way to stop leaking keys is to stop having them. On Azure, managed identities let a workload obtain Microsoft Entra tokens without the application managing credentials. For agents running outside Azure, such as in GitHub Actions or Kubernetes, workload identity federation lets the workload exchange a token from its own trusted issuer for an Entra access token, so no client secret or certificate needs to be stored.

Tokens obtained this way are short-lived, which is what CERT-In asks for. The remaining design work is scoping.

Step 3: one identity per agent run, scoped to the task

A single shared service principal for "the agent" defeats attribution and least privilege. Aim for:

Separate identities per agent role. A summarizing agent and a deployment agent should never share a principal.
Narrow role assignments. Grant data-plane roles on the specific resource the task needs, not Contributor or Owner on a subscription. Read-only by default; write access only where the task is a write.
Per-run attribution. Where the platform allows, tag tokens or log entries with a run identifier so every action traces back to one execution.
No production in evaluation. CERT-In's guidance for AI developers says to use synthetic targets, synthetic credentials and disposable infrastructure, and to keep production data and real credentials out of evaluation environments. The same rule fits internal agent testing.

Keep credentials out of the model's context entirely. The tool layer should hold the token and return results, so a prompt injection cannot ask the model to print it.

Step 4: default-deny egress, enforced by the network

CERT-In is explicit that network restrictions must be enforced at the network layer, not through instructions to the model. A prompt that says "only contact api.example.com" is not a control.

Run agents in a network segment whose outbound traffic passes through a firewall or proxy with an allowlist of required destinations. Block cloud metadata endpoints unless the identity mechanism needs them, and block private ranges the agent has no reason to reach. Log denied connections; an agent trying to reach somewhere unexpected is an early warning. A fuller design, with per-run allowlists and shutdown, is in AI agent kill switches and egress gateways.

Step 5: logs the agent cannot edit

CERT-In asks for a tamper-resistant record of agent activity and, for organizations generally, log retention of at least 180 days. In practice, send agent and tool-call logs to a separate store the agent's identity cannot write to or delete from, such as a central log workspace with restricted access or immutable storage. Record the destination, action, parameters and result for every tool call that touches production.

The advisory's warning for evaluators applies here too: transcript review alone can miss activity that looks legitimate in the model's reasoning. Log what the agent did, not only what it said.

A short checklist

Secret scanning and push protection on every repository; rotate before purging.
No long-lived keys for agents; use managed identity or workload identity federation.
One scoped identity per agent role, read-only by default.
No production credentials or data in test and evaluation runs.
Default-deny egress at the network layer.
Append-only logs outside the agent's reach, retained for at least 180 days.

None of this is new security practice. That is CERT-In's point. Agents simply remove the time you used to have before someone noticed.

Originally published at yadui.dev by Abhinav Yadav.

PHP2Shell: a practical patch and check guide for PHP servers

Abhinav Yadav — Fri, 30 Oct 2026 17:31:51 +0000

What happened

PHP2Shell is the nickname for CVE-2026-109618 and CVE-2026-109619. On October 21, 2026, the PHP project shipped emergency releases, PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, to fix two critical flaws that it says "can allow unauthenticated remote code execution" (PHP security advisory). The day before, PHP had given advance notice that both were rated CVSS v4.0 9.2. If you upgrade, also rotate any secrets a compromised host could have read; the Railway breach the same week shows why.

The two bugs, as PHP describes them:

CVE-2026-109618, RCE via out-of-memory corruption. Out-of-memory handling can interrupt PHP while internal request data is only partly initialized, and request cleanup may then treat that invalid data as valid.
CVE-2026-109619, RCE via stale global state. Request-owned internal state can outlive the memory behind it, and a later request on the same worker may use it before normal initialization resets it.

Two days later, on October 23, PHP published a short informational advisory about a separate issue, CVE-2026-115560. It is not fixed by the October 21 releases. PHP calls it "an unlikely RCE vector" and is handling it in the regular release cycle rather than with another emergency release.

Who is exposed

PHP's own answer for the October 21 flaws is broad: "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed." It considers the risk highest for mod_php, where it has a demonstrated exploit in which an unauthenticated request can trigger the attack before any application code runs (advisory). In other words, a clean application does not protect you. The bug sits in the runtime.

PHP 8.1 and older no longer get updates from the project. PHP published minimal source backports for 7.4, 8.0 and 8.1 for people building from source, and says some distributions and LTS vendors ship backported fixes.

The October 23 issue is much narrower. According to PHP, it needs all of the following: session.serialize_handler set to php_binary or php_serialize in configuration, application code that switches it to php at runtime with ini_set() before session_start(), and session upload progress still enabled. PHP has not said which versions are affected or when the fix ships.

What attackers are doing

Everything in this section comes from The Hacker News, which attributes each claim to the vendor named. I have not verified these against the vendors' own posts.

THN reports that Amazon said its honeypots logged an exploit attempt against both CVEs on October 17, four days before disclosure. It reports Cloudflare saying attempts rose from tens of thousands within 45 minutes of the October 21 disclosure to millions by early October 22. It also reports that Sophos and Arctic Wolf saw attempts to install a Mirai botnet variant, and that Previdian, Wordfence and others report scanning and probing but no confirmed code execution so far.

Read that last point carefully. "No confirmed code execution" is a statement about what defenders have observed, not a guarantee. A pre-disclosure attempt also means someone had details early. Patch as if a working exploit exists.

The checklist

1. Find every PHP runtime you actually run

Check the CLI and the web runtime separately, because they are often different binaries:

php -v
php-fpm -v        # or php-fpm8.3 -v, php-fpm8.4 -v, depending on packaging

For Apache with mod_php, check the loaded module version through your package manager or a phpinfo() page served only to an admin. Remember containers, base images, CI runners and managed hosting.

If you use distribution packages, the upstream version number may not change. PHP notes that Linux distributions and LTS vendors received the patches in advance (advisory). Check your vendor's security tracker for the package version that carries the fix for both CVEs, rather than looking for "8.4.27" in php -v.

2. Upgrade and restart

Move to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your vendor's patched package. Then restart every FPM pool, Apache and any long-running worker. A package upgrade that leaves old workers running has not patched anything. Note that PHP 8.2 reaches end of life on December 31, 2026, per php.net, so plan that upgrade now.

3. Turn off session upload progress

Set this in php.ini, the FPM pool or server configuration, then restart every worker:

session.upload_progress.enabled = 0

PHP lists this as a mitigation for CVE-2026-109619 and says it also covers CVE-2026-115560. PHP warns not to rely on ini_set() or FPM .user.ini for it, because the setting must apply before request parsing. Upload progress is on by default, so check whether any feature of yours depends on it before switching it off.

4. If you truly cannot patch today

PHP is explicit that only an update is a complete fix. Its stopgaps for the October 21 bugs include memory_limit=-1 set in a way applications cannot override, a low post_max_size, request size and part limits at the web server or proxy, fatal_error_backtraces=0 on PHP 8.5, and container or cgroup limits as an availability boundary. It specifically warns against RLIMIT_AS and RLIMIT_DATA, which can cause the vulnerable allocation failure. Read the full list before applying any of these, since several trade availability for exposure.

5. Use your WAF, but do not lean on it

If your WAF or CDN vendor has published managed rules for these CVEs, enable them. Treat them as noise reduction while you patch, not a substitute for patching.

6. Look for signs of a foothold

No indicators have been published that I can verify, so use standard post-exploitation checks on any host that was exposed and unpatched:

New or modified .php files in upload, cache and temp directories, especially files written by the web server user.
New crontab entries for the web user or root, and new systemd timers or services.
Unknown processes running as the web user, and outbound connections from PHP workers to hosts you do not recognize.
Unexpected binaries in /tmp, /var/tmp or /dev/shm, given the reported Mirai attempts.

If you find anything, isolate the host and rebuild from a known-good image rather than cleaning in place. The LiteLLM 1.107.0 incident response guide walks through rebuild and key rotation in more detail.

7. Keep watching

Alert on PHP worker crashes and out-of-memory events, since both bugs involve those paths. Watch request logs for spikes in large or malformed multipart requests, and track your vendor's advisory pages for updated package versions.

FAQ

Which PHP versions fix PHP2Shell?

PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released on October 21, 2026, fix CVE-2026-109618 and CVE-2026-109619. Distribution packages may carry the fix under a different version number, so check your vendor's tracker.

Does a secure application protect me?

No. The bugs sit in the PHP runtime, and PHP describes a mod_php exploit that triggers before any application code runs.

Do the October 21 releases fix CVE-2026-115560?

No. PHP is handling CVE-2026-115560 in its regular release cycle. Setting session.upload_progress.enabled = 0 in server configuration is the listed mitigation.

What comes next

PHP says it will publish a full advisory for CVE-2026-115560 with the next release (php.net). Another fix is already queued: PHP has flagged CVE-2026-115560 for its next routine release, so expect another patch round soon, and keep session.upload_progress.enabled=0 in place until then.

Originally published at yadui.dev by Abhinav Yadav.

LiteLLM 1.107.0 compromise: incident response guide

Abhinav Yadav — Fri, 30 Oct 2026 17:31:13 +0000

What happened

The LiteLLM 1.107.0 compromise began on October 21, 2026, when a compromised litellm==1.107.0 was published to PyPI and to LiteLLM's container registries. LiteLLM's incident post states that earlier versions are safe, that the affected releases were pulled, and that customers on the private enterprise release were not affected. Its attack-chain post says the artifacts were live for about two hours: PyPI releases were frozen by 13:23 UTC and Docker images removed by 14:20 UTC.

Two hours is enough. LiteLLM is commonly deployed as a gateway between applications and model providers, and Microsoft's analysis notes that in that position it may hold model-provider API keys, database connection strings, workload identities and routing configuration. The same package also sits on developer laptops and build agents. If you run an AI gateway, treat this as a template for the next incident, whichever package it is.

Why "I never imported it" is not a defence

The malicious wheel shipped cook.pth, cook.py and sitecustomize.py under its purelib data directory. On install, Microsoft reports, these files landed in the environment's library directory, outside the litellm package folder.

That location matters because of how Python starts. The site module documentation describes how lines in .pth files that begin with import are executed during interpreter initialization, and how Python then attempts to import a sitecustomize module. Microsoft found that cook.pth contained a single line, import cook, which launched a credential collector in a daemon thread. sitecustomize.py carried a separate Unix-oriented loader designed to fetch and execute additional Python code; Microsoft says remote retrieval through that path was not confirmed.

The consequence is stated plainly in the analysis: an application did not need to import LiteLLM for the payload to run. Starting Python in an affected environment could be enough. In one Windows example, a routine Python invocation to install an unrelated dependency activated the collector. And because the startup files lived outside the package folder, deleting litellm could leave them behind.

What the collector went after

Microsoft lists the targets the recovered code was designed to read: AI assistant, IDE and MCP configuration; Git credentials and package-manager configuration; AWS, Azure CLI and Google Cloud credential caches; Kubernetes service-account files and Docker configuration; browser credential data and shell histories; process environments, including other processes' environments readable through procfs on Linux; SSH, GPG and TLS material. On a proxy host, a separate module could use Prisma to read selected fields from two LiteLLM database tables. Microsoft is careful to note that a target appearing in the code does not establish successful access.

Collected data was encrypted with a per-run AES key wrapped by an embedded RSA key and posted to hxxp://www[.]litellm[.]dev/healthcheck. Note the lookalike domain.

Response, in order

Microsoft's guidance and LiteLLM's posts agree on the shape of the response. Here it is as a runbook.

Find every copy. Search installed environments, pip and uv caches, internal mirrors, lock files, build outputs and container images for 1.107.0. LiteLLM's incident post lists affected image tags, including floating ones such as latest, and digests. Mutable tags mean "we pinned to latest" is not an answer; you need to know which digest you actually pulled and when.
Do not run Python to check. Microsoft is explicit: do not run python, pip or anything that invokes the affected interpreter during evidence collection. Each start can re-run the payload. Isolate the host, stop Python processes where safe, prevent automation from restarting them, and inspect the filesystem with trusted tools from a known-clean machine.
Correlate before declaring compromise. Combine file hashes, Python process ancestry, .pc_e_ temporary staging directories, connections to the collector domain, and subsequent use of the identities involved. Package presence alone is not a verdict.
Rebuild, do not clean. Rebuild environments and images from verified artifacts. Confirm cook.pth, cook.py and sitecustomize.py are gone from the library path. Microsoft states that removing the package or a release tag is not sufficient recovery.
Rotate from a clean machine. Rotate everything the affected identity could reach: model-provider keys, cloud and workload credentials, CI/CD secrets, source-control and registry tokens, SSH and GPG keys, AI coding-tool tokens, and on proxy hosts the stored provider credentials and DATABASE_URL. Rotating from a compromised workstation hands the new secret to the same collector. The same rotate-from-clean discipline applied to the Railway breach the same week. Revoke sessions as well; Microsoft points to Entra emergency revocation because rotating a password does not immediately invalidate every active token.

Hardening that would have narrowed the blast radius

Hash-pinned lock files. pip's secure installs guide describes hash-checking mode, in which every requirement must carry a hash and installation fails on a mismatch. A pinned hash for 1.107.0 would not exist in your lock file unless someone added it, so an unreviewed upgrade fails closed.

Image digests, not tags. Microsoft recommends container digests because they identify immutable content. A deployment that references @sha256: does not silently pick up a new latest.

Gated internal mirrors. Admit packages to your mirror only after review, with a delay for brand-new releases. The window here was about two hours.

Egress control. Microsoft's guidance says developer workstations, build agents, test systems, containers and AI gateway hosts should not have unrestricted outbound HTTP unless required, and links to Azure's outbound egress design guide. A gateway host needs to reach model providers and its database. It does not need to reach an arbitrary domain that merely looks like the vendor's.

Keep secrets out of the gateway's process environment where possible. The collector read environment variables, including other processes' on Linux. Secrets fetched at use time from a vault, with short lifetimes, are worth less to a collector than long-lived keys sitting in env.

The lesson upstream: one unrevoked key, one unscoped token

LiteLLM's attack-chain post is unusually candid, and the root causes are ones every team running agents should check for.

On May 27, 2026, a configuration file committed to a public repository inadvertently contained the master key to a deployment of LiteLLM's internal Agent Platform. The commit was force-pushed over and the key was identified as needing revocation. In LiteLLM's words, key revocation did not occur.

That platform let self-hosted agents open pull requests, so it held a GitHub token. The post says the token was not associated with a service account and was not scoped down: it was a GitHub CLI OAuth token belonging to the organization owner. On October 10, the attacker used the master key against the platform's API, which returned that token. With owner access, they ran throwaway CI workflows that posted repository secrets to an external endpoint, collecting tokens for two more maintainers. On October 21 they used the owner token to override branch protection on the release repository and repoint it to a lookalike fork, used one maintainer token to approve the production gate, and another to delete the run records. LiteLLM notes the release approval rule had been relaxed that week to allow any two engineers to approve.

Three checks follow for any team running agents with repository access:

An exposed key is revoked, not just hidden. Force-pushing history does not un-publish a secret.
Agents get their own scoped identity. An agent platform should never hold a human owner's token.
CI secrets are reachable only from protected branches and approved workflows, so a new branch cannot run a job that prints them. Related: why persist-credentials in GitHub Actions matters and Stop giving AI agents your production keys.

FAQ

Was I affected if my application never imported LiteLLM?

Possibly. Microsoft found the payload ran from .pth and sitecustomize.py startup files, so starting Python in an affected environment could be enough.

Is uninstalling litellm 1.107.0 enough?

No. The startup files lived outside the package folder, and Microsoft states that removing the package or a release tag is not sufficient recovery. Rebuild from verified artifacts.

Which secrets should I rotate?

Everything the affected identity could reach, including model-provider keys, cloud and CI/CD credentials, source-control tokens, SSH and GPG keys, and on proxy hosts the stored provider credentials and DATABASE_URL. Rotate from a clean machine and revoke sessions.

How long were the malicious releases available?

About two hours, according to LiteLLM's attack-chain post. PyPI releases were frozen by 13:23 UTC and Docker images removed by 14:20 UTC.

LiteLLM says it will share process changes separately. Until then, the attack-chain post is the clearest public record of how this happened, and it is worth reading in full.

Originally published at yadui.dev by Abhinav Yadav.