Which secrets on a PHP server are most at risk from PHP2Shell?

Which files and secrets are most exposed?

PHP2Shell makes the PHP runtime a read path into anything the process account can access, so the highest-value targets are usually the secrets already sitting in the web application’s filesystem context. That includes environment files, framework or CMS config files, keys and tokens embedded in application code, and private keys or certificates stored on disk.

On many real deployments, the risk is not one secret type but the whole cluster of credentials that accumulate around the app. If the PHP process can read the web root, deployment directory, or shared config volume, an attacker can often enumerate multiple secrets in one pass rather than chasing a single hardcoded value.

For a practical hardening baseline, PHP and WordPress Security Guide is the right starting point because it covers the surrounding PHP and WordPress file layout that commonly keeps these secrets exposed.

Why are application credentials and service-account material so risky?

Application secrets are especially valuable because they frequently unlock more than the immediate PHP site. Database credentials, API keys, bearer tokens, signing keys, and SSH keys can each expand access into adjacent services, admin consoles, or downstream workloads. Once one secret is recovered, the attacker often moves from file read to authenticated access.

Service-account SSH keys deserve particular attention because they can collapse server-level compromise into wider administrative reach. If the same account is used for deployment, backup, or maintenance, the exposed key may become a bridge from a single PHP compromise to broader infrastructure access.

Guide to the Secret Sprawl Challenge is useful here because it frames why scattered credentials in code, config, and pipelines tend to multiply blast radius rather than stay isolated.

What changes on cloud servers and shared infrastructure?

On cloud virtual machines, the exposure can extend beyond files on disk. If the instance can request credentials from the metadata service, a PHP compromise may be enough to obtain temporary cloud access, which can be just as serious as finding a static key in a config file. That makes host-level read access a potential gateway into the cloud control plane.

This is why the most dangerous secrets are often the ones that combine persistence with reach. Long-lived API keys, reused credentials, and permissive instance roles all turn a local PHP flaw into a much larger access problem, especially when the same material works across environments or survives redeployment.

Secrets Management Guide helps connect that exposure pattern to the controls that reduce it, especially centralisation, rotation, and removing secrets from files where the runtime can read them.

Risk and Threat Considerations

The main danger is not just disclosure, it is privilege expansion. A PHP read flaw becomes materially worse when the exposed secret can authenticate to databases, cloud APIs, source repositories, or remote administration channels, because the attacker can reuse that trust immediately or return later with the same access.

Failure mechanism: The attacker uses PHP execution or file-read capability to enumerate readable paths, then extracts credentials, keys, or tokens that were never meant to be reachable from the web runtime. Reuse, long-lived secrets, and overbroad service-account access make that path especially effective.

Impact: One exposed secret can enable data theft, administrative access, lateral movement, token replay, cloud privilege abuse, or persistence well beyond the original PHP server. If metadata-derived credentials are in scope, the compromise may extend into cloud resources even when no static secret is found on disk.

Practitioner Guidance

What to verify: Confirm exactly which paths the PHP user can read, then check whether those paths contain environment files, framework config, private keys, deployment credentials, or tokens used for cloud and SaaS access. The key question is not whether a secret exists, but whether the runtime can reach it and whether it still works.

Decision rule: If a secret can authenticate to production systems, treat it as compromised on first credible exposure and rotate it before you spend time proving exploitation. If the secret only exists in code or disk but has broad downstream reach, prioritise blast-radius reduction and replacement with short-lived or scoped credentials.

Practitioner takeaway: PHP2Shell is dangerous because it turns ordinary file access into credential exposure, so remediation should focus on secret location, runtime reach, and downstream privilege, not only on the PHP bug itself.

Related resources from NHI Mgmt Group

• When do non-human identities pose the greatest risk to organizations?
• Why do non-human identities create more risk than many human accounts?
• Why do non-human identities create more remediation risk than many human accounts?
• What is secrets exposure in NHI security?