Critical PHP Vulnerabilities: 10 Checks Kenyan Businesses Should Run This Week

Security guidance checked on 24 October 2026.

On 21 October, PHP released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that can allow unauthenticated remote code execution. In practical terms, an attacker may be able to run code on a vulnerable server without signing in. The PHP Foundation's explanation describes the issues and the urgency of updating.

If your business runs a PHP website, Laravel application, ordering portal or payment integration, the first question is: has the PHP runtime serving our application actually been patched? A working website and a completed application deployment do not answer that question.

This article is not a claim that Statum or any specific customer is affected or has been compromised. The distributor used below is hypothetical. To establish whether a system is exposed, check its actual runtime, configuration and vendor security updates.

1. Verify the running PHP version and apply the security update now

Do this today. The remaining checks should not delay patching.

The fixed upstream releases announced on 21 October are:

Use the fixed release or a later supported security release in your branch. For distribution packages, confirm the vendor's security notice and package revision because fixes may be backported. PHP's official advisory says updating is the only complete solution; temporary mitigations address specific paths.

Imagine a distributor whose staff use a Laravel portal to record orders, receive M-Pesa payments and send SMS notifications. Its developer's laptop may run a different PHP version from the production web service. A project document may also describe an older environment.

Ask the hosting provider or engineer to record:

• The version and package or container image serving web requests on every production instance.
• The vendor evidence that the installed build contains the fixes.
• Confirmation that the relevant services and long-running processes were restarted or replaced.
• Results of checks covering sign-in, orders, payment callbacks, queues and notifications after the update.

The command php -v checks the selected command-line binary. It does not establish which runtime the web server uses. Verify the web runtime through restricted operational tooling; do not leave a public phpinfo() page online.

Also review PHP's separate 23 October notice

The 23 October session-upload advisory concerns a separate issue, CVE-2026-115560. It requires an unusual combination: upload progress enabled, a configured php_binary or php_serialize session handler, and application code switching to php with ini_set() before session_start().

PHP recommends session.upload_progress.enabled=0 pending the next regular bugfix release. If already applied, keep it; applications that never switch handlers at runtime may retain the feature. Apply the setting in pre-request server configuration and restart all workers; do not rely on a runtime ini_set() call. Review the notice separately from the 21 October fixes.

Evidence to request: a dated runtime inventory, patch confirmation and post-update test results.

2. Make sure the business can recover its critical accounts

The distributor's owner should know who controls its domain registrar, DNS, hosting, code repository and payment-provider accounts.

If your developer becomes unavailable tomorrow, could someone in the business recover the domain and hosting accounts? Record the account owner, recovery contact, billing responsibility and support escalation route. Use individual access for engineers rather than sharing one administrator password.

Check that recovery details remain usable if a staff member leaves or a supplier becomes unavailable. Store recovery information securely, with access limited to the people who need it.

Evidence to request: an account ownership register and a verified recovery route.

3. Enable MFA on administrator and business email accounts

Protect the accounts that can reset passwords, change infrastructure or alter payment settings. For the distributor, that includes business email, hosting, the domain registrar, the source repository and privileged application accounts.

Use multifactor authentication where supported, preferably phishing-resistant methods such as passkeys or security keys. Protect recovery codes separately and agree who can use them.

Kenya's Communications Authority recently encouraged stronger passwords, two-factor authentication and verification of suspicious messages. Check the settings rather than assuming your provider enabled these protections.

Evidence to request: the administrator account list and MFA enrolment status, without collecting anyone's passwords or recovery codes.

4. Remove access that staff and suppliers no longer need

A former salesperson should not retain access to customer records. A supplier who completed a short assignment should not keep indefinite production access.

Review application accounts, hosting access, repository membership, SSH keys and active sessions. Disable unnecessary accounts and revoke associated tokens or keys. Check service accounts carefully before removing them so that a staff access review does not interrupt a legitimate integration.

Make access removal part of staff departures and contract completion, with a named owner.

Evidence to request: a completed access review showing what was removed and what remains justified.

5. Restrict access to refunds, payment settings and customer data

Different jobs need different permissions. The distributor's warehouse team may need to prepare orders without being able to approve refunds, change collection details or export the full customer list.

Identify sensitive actions and decide who can perform them, whether approval is required, and what history must remain. Test these restrictions with representative user accounts. Hiding a button is insufficient if the underlying request still succeeds.

Start with customer exports, refunds, account administration and changes to payment settings.

Evidence to request: a role-and-permission matrix plus results from testing restricted actions.

6. Check how API keys and other secrets are stored

The ordering portal may hold credentials for M-Pesa, SMS, email and its database. List the credentials, their owners, the systems that use them and the access they grant.

Keep secrets out of source code, frontend bundles, public files, support screenshots and ordinary logs. Use the deployment platform's protected configuration or an appropriate secrets manager, with access limited to the required processes and operators.

If a credential may have been exposed, revoke or rotate it through the provider's supported process. Coordinate the change and verify the integration afterward.

Evidence to request: a credential inventory and storage review that records locations and owners without reproducing secret values.

7. Verify payments before releasing goods or services

A customer-facing success screen, screenshot or SMS should not be the authority for dispatching the distributor's goods.

Confirm payment using the enabled provider product's documented verification process, match the reference and amount, and record the result once. Keep unresolved payments visible for reconciliation. Test duplicate notifications, delayed results, mismatched amounts and reversals where the product supports them.

Our M-Pesa callbacks and reconciliation guide explains these decisions. The pre-production checklist provides a structure for reviewing readiness.

Evidence to request: payment test results and an owned queue for unresolved differences.

8. Restore a backup and check what it actually recovers

A successful backup job does not demonstrate that the business can recover.

Restore a recent backup into an isolated environment. Check the database, uploaded documents and other essential records. Confirm that the required configuration and encryption keys can be recovered securely. Prevent the test environment from sending live messages or triggering payment operations.

For the distributor, agree how many hours of orders it could afford to lose and how long it could operate without its portal. Compare those requirements with the recovery test.

Keep backup access separate enough that a compromised application account cannot simply erase every recoverable copy.

Evidence to request: the restoration date, recovered data period, elapsed recovery time and any unresolved gaps.

9. Make sure alerts reach someone who can act

Decide which events require attention: new administrator accounts, unusual privilege changes, unexpected deployments, repeated sign-in failures, backup failures and disruption to payment processing.

Give each alert an owner and an escalation route. Send a test alert through the real channel and confirm that someone receives it. Avoid recording passwords, API keys or unnecessary customer data in logs.

The distributor also needs someone to review payment differences alongside its security alerts. An unexplained payment difference needs investigation even when the website remains available.

Evidence to request: a tested alert route, relevant log retention settings and an agreed response owner.

10. Write down the first steps of an incident response

If someone discovers an unexpected administrator account or suspicious server activity, the team needs a clear route to respond.

Record who can coordinate the incident, contact the hosting provider, restrict access, preserve evidence and communicate with management. Keep the contacts available outside the affected system.

If compromise is suspected, involve qualified responders, preserve relevant records and plan containment and credential rotation. Patching closes a vulnerability; it does not establish whether an attacker previously gained access or remove everything an attacker may have left behind. Assess any reporting obligations with the appropriate legal or privacy lead.

Evidence to request: a short response plan and a walkthrough of one realistic scenario.

What to do today, and what to finish this week

For each check, record an owner, a deadline, the evidence needed and the current status. Separate confirmed results from assumptions.

Prioritise PHP runtime verification and patching immediately. Then address the highest-impact access and recovery gaps. The rest of the week can be used to complete the broader review and agree recurring maintenance responsibilities.

Official sources

• PHP security releases and the separate 23 October session-upload notice.
• PHP Foundation: the 21 October security release.
• Communications Authority of Kenya: cybersecurity and consumer protection, 14 October 2026.

Fixed versions and configuration guidance above reflect the notices checked on 24 October 2026. Check the current vendor guidance before making production changes.