whichphp v0.2.0

whichphp v0.2.0 adds a way to check what a Kubernetes cluster is actually running, and a way to be told when an image tag is fixed. The GitHub Action works the same as in v0.1.1.

What's new

• whichphp cluster reads which image digest each running pod uses (with kubectl get, against the --context you name, nothing else) and checks each image once. Per workload it says whether a redeploy is enough, because the tag already points to a fixed image, or whether the image itself still ships vulnerable PHP and has to be rebuilt. It gives the kubectl rollout restart command, for the same context and kubeconfig, when a redeploy is the fix and the pods pull their tag on every start; with imagePullPolicy: IfNotPresent it says to pin the new digest or change the policy first. It reminds you to save logs before recreating pods. Output as a table or JSON. Exit codes: 0 nothing to do, 1 a workload needs action, 2 an image couldn't be proven fixed or couldn't be checked, 3 an error, such as a cluster that couldn't be read, no running pods to check, Syft or Grype missing, or an interrupted run.
• Atom feeds per tag. The index now publishes a feed for every tracked tag, with an entry each time its status, image digest or verdicts change, and feeds/all.xml with the latest changes across the index. Each tag's details on the index page link to its feed. whichphp index writes the feeds; --site-url sets the links in them.

Fixes

• Tag lookups renew registry tokens when they expire (Docker Hub's last five minutes), so a long run no longer fails with 401 Unauthorized partway through.
• DOCKERHUB_USERNAME and DOCKERHUB_TOKEN are sent only to Docker Hub's own token service, for Docker Hub images, and a token made with them is used only for Docker Hub. Before, any registry whose token URL contained docker.io received them; with cluster mode, the registry can come from any pod spec.
• Syft and Grype errors lose their terminal color codes, and long ones keep their end, where the cause is.

Limits of cluster mode

Settings come from the images: a php.ini mounted from a ConfigMap or set through the environment isn't read yet. An image loaded straight into a node rather than pulled has no registry digest, so the image in the pod spec is checked instead; for a tag, a fixed or no-PHP result counts only when the image ID matches the tag's image. Pods on Windows nodes are skipped when the nodes can be listed. The lookup of what a tag points to now is anonymous, except on Docker Hub with DOCKERHUB_USERNAME and DOCKERHUB_TOKEN, so for a private registry the report may say the tag couldn't be checked.

Verify your download

sha256sum --ignore-missing -c SHA256SUMS        # on macOS: shasum -a 256 --ignore-missing -c SHA256SUMS
gh attestation verify whichphp_0.2.0_linux_amd64.tar.gz --repo yusufyildiz34/whichphp \
  --signer-workflow yusufyildiz34/whichphp/.github/workflows/release.yml --bundle whichphp_0.2.0.sigstore.json

whichphp v0.1.1

A small release of the GitHub Action. The whichphp binary is built from the same code as v0.1.0.

Changes

• Provenance checked without the GitHub API. The action now verifies the release archive against the Sigstore bundle published with each release (whichphp_<version>.sigstore.json). This needs no token and no access to GitHub's attestation API. If the bundle check fails or can't run, for example when Sigstore's trust root is unreachable, the action falls back to the attestation API. Both enforce the same signer workflow and tag, plus the commit for a SHA pin, and the step fails if neither passes.
• SHA pins find their release without a token. The action looks up the release tag for a pinned commit with git ls-remote instead of the GitHub API. Together with the bundle check, tag and SHA pins now also work on GitHub Enterprise Server and GHE.com runners that can reach github.com, release-assets.githubusercontent.com and tuf-repo-cdn.sigstore.dev (plus tuf-repo.github.com with gh older than 2.83).
• No token sent off github.com. On GitHub Enterprise the action no longer sends the job's token, or a GITHUB_TOKEN the job sets, to github.com.
• New install output saying how whichphp was installed: release-verified, release-checksum-only (the runner's gh couldn't check provenance) or source.

Verify your download

sha256sum --ignore-missing -c SHA256SUMS        # on macOS: shasum -a 256 --ignore-missing -c SHA256SUMS
gh attestation verify whichphp_0.1.1_linux_amd64.tar.gz --repo yusufyildiz34/whichphp \
  --signer-workflow yusufyildiz34/whichphp/.github/workflows/release.yml --bundle whichphp_0.1.1.sigstore.json

Without --bundle, gh fetches the same provenance from GitHub's attestation API.

whichphp v0.1.0

The first release of whichphp: find every PHP build inside a container image, without running it, and get a verdict with evidence for the PHP2Shell CVEs (CVE-2026-109618 and CVE-2026-109619).

What's in it

• whichphp image finds the PHP CLI, PHP-FPM, Apache's mod_php, CGI and embedded builds in an image, and gives one verdict per CVE. It reads distro backports (Debian, Ubuntu, Alpine, RHEL and others), recognizes end-of-life branches and third-party builds (Sury, Remi), and reports the effective session.upload_progress.enabled, the only mitigation for the still-unfixed CVE-2026-115560.
• Output as a table, JSON, SARIF for GitHub code scanning, or OpenVEX. Repeat -o to write several in one run.
• A GitHub Action that checks an image in CI, writes the result to the job summary, fails the step when action is needed, and can upload to code scanning.
• A daily public index of popular PHP images on amd64 and arm64: https://yusufyildiz34.github.io/whichphp/

Verify your download

Every archive has a SHA-256 in SHA256SUMS and signed build provenance from this repository's release workflow:

sha256sum --ignore-missing -c SHA256SUMS        # on macOS: shasum -a 256 --ignore-missing -c SHA256SUMS
gh attestation verify whichphp_0.1.0_linux_amd64.tar.gz --repo yusufyildiz34/whichphp

whichphp_0.1.0.sigstore.json is the same provenance as a bundle. Pass it with --bundle to check a download without GitHub's attestation API.

Known limits

A verdict covers the image as published, not settings changed at runtime, and says nothing about whether a system was compromised before it was fixed. See what a verdict does not prove.