PHP security checklist: 8 steps to find and fix vulnerabilities

php icon.
Head of Engineering
Verified expert
Every article at Innowise is created by authors with real-world experience. They understand the topic beyond theory and bring insight from real projects.
7+ years of experience
Verified expert
7+ years of experience
Herman leads engineering departments and builds the processes, team structures, and technical standards they need to scale. His expertise covers high-load backend systems, delivery management, and engineering leadership.
Expertise
High-load systems Software architecture Databases
Let's talk

Key takeaways

  • PHP2Shell requires urgent patching. On 21 October 2026, PHP fixed CVE-2026-109618 and CVE-2026-109619. Both are critical runtime vulnerabilities (CVSS v4.0: 9.2) that can allow unauthenticated remote code execution.
  • Check the patched versions. The first fixed releases are PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Linux distributions may provide the same fixes through backported patches.
  • Prioritize exposed PHP runtimes. Apache mod_php carries the highest reported risk, but PHP-FPM and other web-facing setups also need attention. Framework updates and composer audit won’t fix PHP2Shell.
  • Don’t stop at patching PHP. Use the eight-step checklist to review dependencies, application code, server settings, and other security weaknesses.
  • Verify the fix in production. Ask your team for a report showing which PHP builds are actually running, which workloads have been patched, and whether there are signs of earlier compromise.
Summarize article with AI

According to W3Techs, PHP powers about 70% of websites where the server-side language is known. Because PHP is so common, a vulnerability in the interpreter can put many sites at risk, even if their own code is secure.

On 21 October 2026, the PHP project released emergency patches for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, together called PHP2Shell. Both scored 9.2 under CVSS v4.0 and allow unauthenticated remote code execution. These flaws affect PHP’s internal memory and request handling.

The first patches were released in PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. If your system uses one of the affected versions, update PHP right away and make sure your web server is running the patched version. But the work shouldn’t end there. For teams that build and maintain PHP applications, including Innowise’s PHP development specialists, the October release is also a reason to review dependencies, application code, and server settings.

In this guide, I’ll show you eight steps to find and fix vulnerabilities in your PHP setup and confirm that your fixes work in production.

Expert breakdown: how PHP2Shell differs from a routine dependency CVE

A vulnerable Composer package affects code your application uses. PHP2Shell is different. Both vulnerabilities are inside the PHP interpreter itself, and an attacker may trigger them before Laravel, Symfony, or another framework even starts running. Updating CMS plugins or Composer dependencies won’t patch PHP, and composer audit won’t detect these runtime vulnerabilities.

The PHP security team identifies Apache mod_php as the highest-risk setup for CVE-2026-109618, with a demonstrated attack that works before application code executes. PHP-FPM, CGI, and other web-serving configurations are also affected, although exploitation conditions differ. Researchers have also demonstrated CVE-2026-109619 exploitation against PHP-FPM.

Here’s what goes wrong in each case:

CVERoot causeWhy teams should care
CVE-2026-109618If PHP runs out of memory while processing a request, some internal data may be left in an invalid state. When PHP cleans up the failed request, it may use that data.If PHP runs out of memory while processing a request, some internal data may be left in an invalid state. When PHP cleans up the failed request, it may use that data.
CVE-2026-109619A PHP worker may keep a reference to memory that was freed after an earlier request. When the worker handles another request, it may try to use that old reference.The problem can carry over between requests handled by the same worker. Checking individual application requests won't necessarily reveal it.

Both flaws can lead to remote code execution without authentication. The fix belongs in the PHP runtime, not in the application’s dependencies.

For a deeper technical explanation, you can check the PHP project’s advisories for CVE-2026-109618 and CVE-2026-109619.

Where do PHP security vulnerabilities come from?

As I mentioned earlier, updating PHP won’t fix a vulnerable Composer package, and a clean dependency scan won’t catch problems in your own code. When reviewing a PHP application, I look at four sources of security risk, each with its own potential consequences.

CategoryExamplesMain risk
PHP runtimeUnpatched PHP versions, interpreter vulnerabilities, unsupported releasesAttackers exploit flaws in PHP itself, regardless of how securely the application is written
Third-party dependenciesComposer packages, CMS plugins, frameworksVulnerable third-party code exposes applications to attacks even when your own code is secure
Application codeSQL injection, XSS, CSRF, insecure deserialization, broken access controlCoding flaws may let attackers steal data, perform unauthorized actions, or compromise the application
Configuration and infrastructureInsecure PHP settings, exposed files, excessive permissionsMisconfigurations may expose sensitive information or give attackers more access than intended

Address PHP vulnerabilities before they escalate

PHP security checklist: 8 essential checks

Next, let’s go through eight security checks I’d use for an existing PHP application. I’d start with the PHP runtime serving live requests, then review the code, dependencies, and configuration for issues a PHP update alone won’t address.

Check your PHP version and security patches

First, identify which PHP runtimes your applications use: Apache mod_php, PHP-FPM, php-cgi, FrankenPHP, or LiteSpeed. Include separate FPM pools, containers, CLI installations, queue workers, and scheduled jobs.

Don’t rely on php -v or php –ini alone. php -v shows the CLI version, while php –ini shows its configuration. Neither confirms the PHP runtime serving web requests.

Compare the active runtime and its configuration with the official PHP advisory, including affected versions and exposure conditions. Apache mod_php has the strongest demonstrated PHP2Shell exposure, including an exploit path before application code runs. PHP-FPM exposure depends on configuration and execution paths. Other SAPIs also need assessment, as the SAPI alone doesn’t establish whether a deployment is safe.

The first upstream releases containing both fixes were:

PHP branchFirst fixed release
8.28.2.35
8.38.3.36
8.48.4.27
8.58.5.12

These versions are listed in the PHP advisories for CVE-2026-109618 and CVE-2026-109619. Check for newer security releases before updating.

Verify PHP patches on Linux and in containers

Check the active runtime. Review your web-server configuration to identify the PHP module, FPM pool, or embedded SAPI handling requests. Confirm its version using access-restricted diagnostics, and remove any temporary endpoints afterward. Never expose phpinfo() or a version endpoint publicly.

Check installed packages. On Ubuntu with PHP 8.3, these read-only commands show installed packages and available versions:

dpkg-query -W 'php8.3*'
apt-cache policy php8.3-fpm

Adjust package names for your PHP branch and compare the installed versions with the vendor’s security notice or package changelog. Linux vendors may backport fixes into older PHP versions. For example, Ubuntu lists these patched builds:

  • Ubuntu 24.04: 8.3.6-0ubuntu0.24.04.13

  • Ubuntu 22.04: 8.1.2-1ubuntu2.28

Both contain the relevant fixes despite their lower version numbers. Check the Ubuntu security notice.

Patch and redeploy. Install the patched packages. For containers, record the running image digest, update vulnerable PHP base images, rebuild, and redeploy affected workloads, including queue workers.

Verify the result. Restart or replace affected PHP workers and confirm that running processes and containers use patched builds or verified vendor backports. Record package versions, running image digests, restart details, and verification results.

PHP 8.1 and earlier are no longer supported upstream, although some vendors still provide security backports. Check whether your installed build is covered and upgrade if it isn’t. PHP 8.2 security support ends on 31 December 2026, so pair any short-term patch with an upgrade plan. You can find the full support timeline in the PHP support schedule.

Audit dependencies and frameworks

Start with composer.lock. It records the package versions your application depends on, including those installed indirectly through other packages. Run these two commands:

composer audit --locked
composer outdated

composer audit --locked checks the locked versions against known security advisories and can flag abandoned packages. composer outdated shows which updates are available, but an outdated package isn’t necessarily vulnerable. Check Laravel or Symfony advisories too, especially if your framework version is no longer supported.

Compare the packages deployed in production with the versions in the audited lock file. Keep the audit results and installed-package inventory with your release records.

If you find vulnerable packages, update them to compatible patched versions and test the affected functionality. Replace libraries that no longer receive security fixes. If compatibility issues block a framework upgrade, document them and the migration work needed. Don’t overlook CMS plugins or libraries installed outside Composer.

A clean Composer audit doesn’t confirm that PHP2Shell is fixed. The audit checks Composer packages, while PHP2Shell requires a separate check of the PHP interpreter and its patches. To assess the application itself, use SAST to analyze source code and DAST to test the running application.

Review PHP and server configurations

Check the PHP settings actually used by your web server, including PHP-FPM pool overrides and loaded extensions. Remember that php --ini shows the CLI configuration, which may differ from the live application.

For production, start with:

display_errors = Off
log_errors = On

Keep logs outside publicly accessible directories and restrict access to them. Remove public phpinfo() pages and debug endpoints, and review expose_php, unnecessary extensions, and filesystem permissions.

Disabling display_errors reduces information disclosure, but doesn’t mitigate CVE-2026-109619. The vulnerable code path may run before PHP handles the error message.

Temporary measures when PHP patching is delayed

If patching must wait, follow the official PHP advisory for your configuration.

  • CVE-2026-109619: Disable session.upload_progress.enabled and, on PHP 8.5, set fatal_error_backtraces=0. Apply these settings before request processing through the server or pool configuration, then restart affected workers. Other exploit paths may remain.

  • CVE-2026-109618: Enforce memory_limit=-1 at server or pool level and restart affected workers. This removes the predictable PHP memory-limit failure path but leaves other allocation failures possible. Check request limits and host or container memory protections to reduce denial-of-service risks.

PHP also published a separate advisory for CVE-2026-115560 on 23 October. It concerns applications that switch session.serialize_handler from php_binary or php_serialize to php using ini_set() before session_start(), with upload progress enabled. Affected setups should disable upload progress pending a fix.

Get an upgrade plan for the legacy PHP apps your business depends on

Check for SQL injection, XSS, and unsafe code execution

Poorly handled user input can expose sensitive data or let attackers run malicious code. I recommend you use code review to trace risky input paths and SAST to flag possible vulnerabilities. Authorized DAST tests the running application, while penetration testing helps determine which weaknesses attackers could exploit. Apps built through vibe coding can have the same flaws and need the same checks.

SQL injection

SQL injection happens when user input changes the structure of a database query. Check how your application builds queries, especially in search forms and reports.

To keep user input separate from SQL commands, use PDO prepared statements:

$stmt = $pdo->prepare(
    'SELECT id FROM users WHERE email = :email'
);
$stmt->execute(['email' => $email]);

Prepared statements keep data values separate from SQL syntax, as the :email placeholder does in the example. But placeholders can’t represent table or column names. For example, if users can sort a report, select the allowed columns from a list defined in the application. Test the affected queries after making changes.

Cross-site scripting

Cross-site scripting (XSS) occurs when an application displays untrusted data that a browser can execute as code. Check PHP templates for user input displayed without proper escaping, especially where automatic escaping is disabled.

For example, if your application displays a user’s name as HTML text, use htmlspecialchars() to convert special characters so the browser treats them as text:

echo htmlspecialchars(
    $name,
    ENT_QUOTES | ENT_SUBSTITUTE,
    'UTF-8'
);

The right protection depends on where the data appears. JavaScript, URLs, and HTML attributes require context-specific checks and encoding. If users can submit formatted HTML, use an HTML sanitizer to remove unsafe elements while keeping permitted formatting.

Unsafe code and command execution

Some PHP functions can execute system commands or PHP code. Check whether untrusted input reaches exec(), shell_exec(), or eval(). Also review dynamic file inclusion and the use of unserialize() with data from untrusted sources.

Where possible, use a PHP API instead of running a shell command. If you need to start an external program, specify the executable and pass its arguments separately. Here’s an example using Symfony Process:

use Symfony\Component\Process\Process;

// Validate $filePath against approved paths first.
$process = new Process([
    '/usr/bin/file',
    '--',
    $filePath
]);
$process->mustRun();

This example uses the file utility to identify a file’s type. Symfony Process passes $filePath as a separate argument rather than inserting it into a shell command string. You still need to validate the path, restrict the service account’s filesystem access, and allow only the operations your application requires.

Deserialization needs a separate check. Avoid passing untrusted data to unserialize(), even with allowed_classes restrictions. Where suitable, use JSON instead and validate the decoded values.

Review authentication, sessions, and access control

Start with passwords. They shouldn’t be stored in a readable form. Check that your application uses PHP’s password_hash() and password_verify(), or the equivalent framework methods. Look for older hashing code that may no longer be secure.

Next, check what happens when someone logs in. The application should generate a new session ID so an ID obtained before login cannot be reused to access the account. Review session.use_strict_mode and cookie settings like Secure, HttpOnly, and SameSite. Test session ID regeneration through your framework, including when multiple requests arrive at once.

Now test whether users can see data that doesn’t belong to them. Create two test accounts, each with its own invoice. Log in to the first account and change the invoice ID in a request to the one belonging to the second account. The server should deny access unless that user has permission.

Repeat the test for editing invoices, downloading files, and API requests. Check that regular users cannot access admin functions. Being logged in doesn’t automatically give someone permission to access every record. The server must check permissions for every request to a protected record or API endpoint.

Verify CSRF protection

A CSRF attack tricks a logged-in user’s browser into performing an action they didn’t authorize, such as changing account details. Start by checking forms and requests that modify data, especially those authenticated through session cookies.

Review the CSRF protection in your Laravel or Symfony application and check whether any routes are excluded. Where token validation applies, test requests with missing or invalid tokens. Also check that forged requests from another website cannot change user data. Check the SameSite setting on session cookies as well.

In Laravel Blade, @csrf adds a hidden token field to a form:

<form method="POST" action="/profile">
    @csrf
    <button type="submit">Save changes</button>
</form>

There’s an important detail in Laravel 13. Its CSRF middleware first checks the Sec-Fetch-Site header. A same-origin request may pass without a token, while other requests fall back to token validation by default. Laravel also disables CSRF protection during automated tests by default, so make sure it’s enabled when testing these defenses.

For APIs, the authentication method matters. A stateless API using bearer tokens in authorization headers generally faces different CSRF risks. But if your SPA relies on session cookies, it still needs protection against forged requests.

Secure file uploads and file access

File uploads become a security risk when attackers can upload executable files or access data they shouldn’t see. Check which file types and sizes your application accepts, where uploads are stored, and who can download them. Test upload and download routes for path traversal, make sure uploaded files cannot run as PHP, and check that .env, .git, and backup files aren’t publicly accessible.

Below is a PHP example that checks an uploaded file’s MIME type and saves it under a randomly generated name:

if (($_FILES['file']['error'] ?? null) !== UPLOAD_ERR_OK) {
    throw new RuntimeException('Upload failed');
}

$tmp = $_FILES['file']['tmp_name'];
$allowed = ['image/jpeg' => 'jpg', 'image/png' => 'png'];
$mime = (new finfo(FILEINFO_MIME_TYPE))->file($tmp);

if (!isset($allowed[$mime])) {
    throw new RuntimeException('Unsupported file type');
}

$name = bin2hex(random_bytes(16)) . '.' . $allowed[$mime];
$target = '/var/app/private-uploads/' . $name;

if (!move_uploaded_file($tmp, $target)) {
    throw new RuntimeException('Unable to save upload');
}

The example assumes a single file upload and an existing, private directory with appropriate permissions. PHP’s move_uploaded_file() confirms that the source was uploaded through PHP’s HTTP POST mechanism.

MIME checking alone isn’t enough to make uploads safe. Production code also needs server-enforced file-size limits, upload and download permissions, and validation of the actual file contents. Re-encode images where appropriate and consider malware scanning for higher-risk uploads. Keep files outside the web root where practical, restrict filesystem access, and prevent uploaded files from executing as PHP.

Protect sensitive data and credentials

Exposed database passwords, API keys, and access tokens can give attackers access to your application or sensitive data. Check your source code and Git history for these secrets. Tools like Gitleaks can help find them. Make sure .env files aren’t stored in Git or accessible over the web. Also review who can access secrets in CI/CD pipelines, and check container images and application logs for sensitive information.

Keep secrets in a secrets manager or another system with restricted access, rather than in application code. Limit who can view or change them, and give each application only the permissions it needs.

If a credential is exposed, revoke or replace it and update the services that use it. Remove exposed copies, investigate whether someone used it without permission, and prevent secrets from appearing in future logs. Removing a secret from your code doesn’t disable it or erase it from old Git commits.

Get an expert PHP security assessment

How to prioritize, deploy, and verify PHP security fixes

01
Prioritize vulnerabilities

Prioritize systems exposed to attacks. Weigh CVSS alongside the PHP SAPI, internet exposure, existing protections, and business impact. Unpatched, internet-facing mod_php workloads need urgent attention, while other SAPIs still require assessment.

02
Deploy patches safely

Record affected applications, PHP worker pools, and container image digests. Test in staging and prepare a recovery plan before deployment. Patch affected packages or rebuild images, then restart or replace all affected workers. WAF rules and configuration mitigations may reduce exposure to specific exploit paths. They do not patch the vulnerable runtime.

03
Verify remediation

Check which PHP build serves live requests and confirm its patch status, including any vendor backport. Verify that affected workers have been restarted or replaced, run regression tests, and repeat the previously failed security check. Monitor production for errors after deployment.

04
Investigate possible compromise

Patching addresses the vulnerability. Any earlier compromise still requires investigation. Review server logs, worker crashes, unfamiliar files, and suspicious network activity. On mod_php, PHP2Shell may execute before application logging begins, so clean framework logs cannot rule out an attack. Escalate warning signs to incident response and preserve the evidence.

05
Maintain security

Track new PHP and dependency vulnerabilities, and add security checks to CI/CD. Base regular assessments on application exposure and business risk, and reassess after major changes or critical disclosures.

arrow-icon.arrow-icon.
01 Prioritize vulnerabilities

Prioritize systems exposed to attacks. Weigh CVSS alongside the PHP SAPI, internet exposure, existing protections, and business impact. Unpatched, internet-facing mod_php workloads need urgent attention, while other SAPIs still require assessment.

arrow-icon.arrow-icon.
02 Deploy patches safely

Record affected applications, PHP worker pools, and container image digests. Test in staging and prepare a recovery plan before deployment. Patch affected packages or rebuild images, then restart or replace all affected workers. WAF rules and configuration mitigations may reduce exposure to specific exploit paths. They do not patch the vulnerable runtime.

arrow-icon.arrow-icon.
03 Verify remediation

Check which PHP build serves live requests and confirm its patch status, including any vendor backport. Verify that affected workers have been restarted or replaced, run regression tests, and repeat the previously failed security check. Monitor production for errors after deployment.

arrow-icon.arrow-icon.
04 Investigate possible compromise

Patching addresses the vulnerability. Any earlier compromise still requires investigation. Review server logs, worker crashes, unfamiliar files, and suspicious network activity. On mod_php, PHP2Shell may execute before application logging begins, so clean framework logs cannot rule out an attack. Escalate warning signs to incident response and preserve the evidence.

arrow-icon.arrow-icon.
05 Maintain security

Track new PHP and dependency vulnerabilities, and add security checks to CI/CD. Base regular assessments on application exposure and business risk, and reassess after major changes or critical disclosures.

Worked example: a production patch that looks successful but is not

A Symfony shop runs PHP 8.3 behind nginx and PHP-FPM. The administrator updates the OS packages and runs php -v. The command shows a patched version, so everything looks fine. But php -v checks only the command-line PHP binary.

Customer requests still go through nginx to PHP-FPM workers that started before the update. Background jobs also run in a separate container with a vulnerable PHP base layer. The packages may be updated on the server, but these workloads are still running the old code.

PHP build checks for web, workers, and CLI.

To finish the patch, the team needs to identify every affected application and worker pool, restart the FPM workers, and redeploy the queue container with a patched image. They must then verify that the running PHP processes use fixed builds or verified vendor backports.

Test checkout and file uploads in staging, run production smoke tests, and repeat the security checks that previously failed. The deployment record should include the PHP SAPI serving web traffic, verified package versions or image digests, restart and test evidence, and the owner.

A passing composer audit isn’t proof that PHP2Shell has been fixed. That command checks dependencies, not the PHP interpreter handling web requests.

Review the PHP worker’s user ID, writable directories, mounted secrets, database permissions, and outbound network access. These determine whether an attacker could modify application files, read credentials, or reach other systems. Least privilege and network segmentation may limit the damage if a worker is compromised, but patching the interpreter remains necessary.

php -v shows the command-line PHP version, but it can’t confirm which interpreter serves production traffic or whether long-running workers are still using the vulnerable build. With PHP2Shell, we verify the active runtime first, then review dependencies and application code. We consider remediation complete only after confirming that the patched version is actually handling production requests.
Stanislav Kazanov, Head of GRC and Cybersecurity.
Stanislav Kazanov
Head of GRC, Cybersecurity & Sustainability

How Innowise can help secure your PHP applications

At Innowise, we bring PHP development and security expertise together. Our 100+ PHP developers have delivered over 250 projects, and our 50+ cybersecurity engineers help identify and address vulnerabilities. Our work is also backed by ISO/IEC 27001:2022 and ISO 9001:2015 certifications.

We check your PHP applications for security issues, including vulnerable dependencies and outdated components. Our developers handle the necessary fixes and upgrades, while security engineers test the changes before release. If you’re unsure where to start, our IT security consulting team can assess the risks and help prioritize the work.

ISO 27001 icon.
ISO-27017-2015.
ISO-27018 icon.
ISO 9001 icon.

Our PHP projects

MedSpa Network website redesign and rebuild
Innowise rebuilt MedSpa Network’s website on WordPress, giving its team control over day-to-day content updates.
2 months from kickoff to launch
3-5 leads per week up from 1 per month
View case study
Client review
View case study
Client review logo. Client review
MedSpa Network website redesign and rebuild.
AI bot for TBC Bank marketing campaign
Innowise built a bilingual Telegram bot that generates AI selfies with TBC Bank's football-star brand ambassador.
3,000 users engaged
2 languages supported
View case study
Client review
View case study
Client review logo. Client review
AI Telegram bot..
Defining the product strategy for Bitlendex’s bitcoin lending platform
Innowise conducted a discovery phase for Bitlendex, helping the client transform an early-stage product concept into a validated business model and clearly defined MVP.
1 month for a full discovery phase
Financial advisory system for Bonnfinanz
Innowise helped Bonnfinanz to build a web-based advisory and administration system that supports mobile working and direct interaction with the client.
EV charging platform with flexible billing
Innowise helped modernize SMART/LAB’s e-mobility platform by enhancing its billing, payment, transaction management, and reporting capabilities.
>50% faster billing and payment processing
FinXP’s cloud-native DevOps transformation
Innowise helped FinXP modernize its financial services infrastructure by migrating legacy PHP-based APIs and applications to a cloud-native architecture.
11 apps moved to Azure App Service
100% Infrastructure as Code
Technical SEO for e-commerce platform
Innowise addressed critical technical SEO and performance issues across Officine 08’s e-commerce platform.
<500 ms server response time
5 months to complete the project
View case study
Client review
View case study
Client review logo. Client review
Technical SEO for e-commerce platform.
Continuous development of a fragrance subscription platform
Innowise helped Scentbird expand its subscription platform to support new shopping experiences and international growth.
4 years of continuous support
View case study
Client review
View case study
Client review logo. Client review
Continuous development of a fragrance subscription platform.
01 / 01
Close popup icon

Conclusion

PHP2Shell exposed a serious risk in the PHP interpreter itself. Framework updates and dependency checks won’t fix vulnerabilities at that level. Companies need to identify every PHP runtime handling web requests, install the security updates, and verify that production servers are running the patched versions.

PHP security also requires regular checks of application code, configuration, and access controls, particularly after critical vulnerability disclosures or major updates. If you need help assessing your exposure or verifying the fixes, Innowise’s IT security consulting and cybersecurity assessment teams can support that work.

FAQ

Your application may be at risk if your server runs a PHP version that hasn't been patched for CVE-2026-109618 and CVE-2026-109619. Check which PHP version is actually running and whether your hosting provider has applied the fixes. Apache mod_php has the highest confirmed risk, but PHP-FPM also needs checking. Since the vulnerabilities are in PHP itself, updating WordPress or another framework won't fix them.

PHP2Shell fixes are available in PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Some Linux vendors have backported the patches to older builds, so check your vendor's advisory. Make sure your running PHP workers use the patched build. On Windows, install the updated October 26 packages ending in -1, which also fix a separate Brotli vulnerability.

If you can't update PHP right away, restrict public access to affected applications where possible. For sites that must stay online, your server administrator can apply temporary measures from the PHP security advisory, such as limiting request sizes or disabling session upload progress. Test these changes to make sure the site still works. They only reduce the risk, so installing a patched PHP version remains urgent.

No. Updating PHP fixes vulnerabilities in the PHP runtime, but it won't fix security issues in your application code, outdated plugins, or server configuration. You need to check and address those separately.

I'd recommend checking PHP applications for known vulnerabilities at least monthly, with more frequent checks for high-risk systems. Monitor PHP security advisories and dependencies continuously, and schedule more thorough audits based on your application's exposure and business risk. Additional testing is important after major updates or critical vulnerability disclosures.

Check PHP security advisories and your hosting or OS vendor's bulletins for known vulnerabilities. Use composer audit --locked to check dependencies, static analysis and code review to find application-level issues, and OWASP ZAP to test your web application with permission. To verify security patches, check the PHP version running in production and any fixes backported by your vendor.

Yes. Updates can cause compatibility issues with older code or extensions. Test them in staging before updating your live application, and have a recovery plan ready in case something breaks.

Correlate reverse-proxy, Apache/nginx, PHP-FPM, and EDR/host logs. Look for worker crashes, suspicious files or processes, unexpected outbound traffic, and signs of credential exposure. Application logs may miss PHP runtime exploits that occur before the framework starts logging. If you find suspicious activity, initiate incident response and preserve forensic evidence.

Show more Show less

Table of contents

Find out which PHP workloads need a security update first

    Contact us

    Book a call or fill out the form below and we’ll get back to you once we’ve processed your request.

    Send us a voice message
    Attach documents
    Upload file

    You can attach 1 file up to 2MB. Valid file formats: pdf, jpg, jpeg, png.

    By clicking Send, you consent to Innowise processing your personal data per our Privacy Policy to provide you with relevant information. By submitting your phone number, you agree that we may contact you via voice calls, SMS, and messaging apps. Calling, message, and data rates may apply.

    You can also send us your request
    to contact@innowise.com
    What happens next?
    1

    Once we’ve received and processed your request, we’ll get back to you to detail your project needs and sign an NDA to ensure confidentiality.

    2

    After examining your wants, needs, and expectations, our team will devise a project proposal with the scope of work, team size, time, and cost estimates.

    3

    We’ll arrange a meeting with you to discuss the offer and nail down the details.

    4

    Finally, we’ll sign a contract and start working on your project right away.

    More services we cover

    arrow