Security & vulnerability response

Fix it before someone else finds it.

Security: Scan & Fix and Security Retainer are for businesses that run a website or an internal system. AI scans the code, an engineer confirms each finding, and we patch and retest before handover. The October 2026 PHP2Shell case showed that a flaw sitting in PHP for over a decade can be attacked before a patch even exists, and that similar old flaws may be sitting in other technologies, not just PHP.

We quote after a short call. You do not need to send source code to start the conversation.

iplus-scan · sample run
complete

Six stages

  1. ✓Read the source code
  2. ✓Check dependencies
  3. ✓Review config and public entry points
  4. ✓Engineer reviews each finding
  5. ✓Patch and regression-test
  6. ✓Report ranked by severity

Findings 6

  • Highapp/Orders/Search.php:88

    User input goes straight into an SQL query

    Fix Parameterize the query, add a test

  • Criticalcomposer.lock · image-lib

    Image library with a published remote code execution flaw

    Fix Upgrade to the patched release, re-run tests

  • MediumDockerfile · PHP 7.4

    Runtime is end-of-life, no official patches

    Fix Plan the version upgrade

  • Highadmin.example.com

    Admin panel open to the internet, origin IP exposed

    Fix Put behind Cloudflare/WAF, allow trusted IPs only

  • Medium.env.bak

    API key still in git history

    Fix Revoke the key, issue a new one

  • False positivevendor/dev-tools

    eval() inside a test-only library, never reaches production

    Dropped by engineer

5 real findings, 1 false positive removed before it reached you.illustrative

This data only shows how a scan runs. It is not any client's result.

iPlus is hiring

iPlus helps companies in Vietnam and Japan hire for a wide range of AI roles, with competitive pay and benefits.

Priority roleAI EngineerNagoya/Osaka/Tokyo, Japan¥4,000,000 – ¥8,000,000 / year
Start for free
FreeUp to 10 companies a month

Quick external check of your website

We look at your website from the outside, with passive methods only and no attacks, and report what an attacker can already see.

Within 3 business days

No obligation. The result is yours to keep.

You send

  • The domain to check
  • Your request, sent from an email address on that domain, to confirm you own it

You receive

  • A one- to two-page report
  • Software versions visible from outside, checked against published CVEs
  • TLS configuration and security headers
  • Whether the origin IP is exposed, and your email SPF/DMARC setup

Next step, if it fits: Security: Scan & Fix, for the source code and internal systems.

What happened with PHP2Shell

The first exploit attempt came four days before the patch.

PHP2Shell is the name for two critical vulnerabilities (CVE-2026-109618 and CVE-2026-109619, CVSS 4.0 score 9.2) inside the PHP engine itself. The cause is memory safety: when PHP hits a fatal error, such as running out of memory mid-request, half-built or already freed data can be reused, and an attacker can turn that into running code on the server with no login. According to W3Techs, PHP runs 69.2% of the websites whose server-side language is known.

  1. 2012

    The vulnerable code has been in PHP since version 5.4.

  2. 2024

    A PHP developer finds the first signs while working on audit results. No one could show a practical exploit, and the fix stalled for months because it was hard to do without breaking compatibility.

  3. Aug 11, 2026

    Security firm Calif reports a remote code execution flaw with the same root cause. Wiz and OpenAI report further attack paths; Wiz says it used frontier AI models. It is 71 days from here to the patch.

  4. Oct 17

    Amazon's honeypot is probed, four days before disclosure and with no public patch. Amazon says it is unclear how the actor got the information.

  5. Oct 20

    Around 15:00 UTC the CVE IDs start circulating online, without technical details. A few hours later, a proof-of-concept video is published by mistake.

  6. Oct 21, morning

    More than six hours before release, a distributor publishes patched builds early. From here anyone can compare them to find the fix.

  7. Oct 21

    Patches ship: 8.2.35, 8.3.36, 8.4.27, 8.5.12. Within the day, Cloudflare's network sees millions of attempts.

  8. Oct 21

    Same day, Node.js fixes a flaw that can lead to remote code execution (CVE-2026-111497), found by an AI-assisted team.

“AI-assisted analysis makes it cheaper to turn a patch diff or advisory into a working exploit.”Amazon Threat Intelligence, on the trend after PHP2Shell
Read the full technical analysis on the blog

Figures come from the PHP2Shell analysis on the iPlus blog and the original notices from the PHP Foundation, Amazon and Wiz.

Why this is not just a PHP story

Old bugs, but the cost of exploiting them has dropped sharply.

PHP2Shell is not a rare kind of bug. What changed is the tooling. The same pressure will reach every component that sits close to untrusted input: language runtimes, compression and image libraries, web servers, and firmware.

01

AI turned “too hard to exploit” into exploitable

In 2024 this flaw stayed a theory because no one could show how to exploit it. In 2026, Wiz used frontier AI models to build working exploits against WordPress, Drupal and Joomla, and wrote that one researcher did in a week what used to take a world-class team months.

02

Once technical details are out, the time to react is short

New proofs of concept appeared within hours of the patch. Amazon's assessment is that AI makes it cheaper to turn a patch or advisory into a working exploit, so more actors can move sooner. That is a statement about the trend: no source confirms the attackers in this case used AI. Even so, a 7-day or 30-day patch cycle assumes a delay that no longer exists.

03

Same day, another technology got named

Node.js fixed CVE-2026-111497 on October 21. The PHP security team says it has published 15 CVEs since July 1 and worked through more than 100 invalid reports, as AI multiplies the volume. Old bugs once dismissed as too hard to exploit are back on the table.

There is no permanent fix for a world where finding bugs and turning them into attack tools keeps getting cheaper. There is only a faster loop: know what you run, patch within hours, assume a breach has occurred, monitor in real time, and use the same kind of AI attackers will use to review your own code first.

What we do

Six steps, each with a concrete deliverable.

Machines do the fast, wide part. Engineers do the part that needs judgment. Every step closes with a concrete deliverable, not a promise.

Main toolsClaude CodeCloudflare WAF
  1. 01

    AI scans your code and dependencies

    AI reads your code and dependency list for vulnerabilities. An engineer reviews each finding, filters out false positives, and rates severity by its real impact on your system.

    You receiveFindings report, ranked by severity
  2. 02

    Patch the holes

    We fix each confirmed vulnerability, most severe first. Changes are small and separate so your team can read and approve them.

    You receivePatched code, delivered as pull requests
  3. 03

    Regression testing

    We re-run the critical flows so the fix breaks nothing else. Where tests are missing, we add them for the area we just changed.

    You receiveRegression test report
  4. 04

    Upgrade versions, harden configuration

    Move runtimes and libraries to supported releases, close ports and permissions you do not need, revoke leaked keys.

    You receiveUpgrade log and a list of config changes
  5. 05

    Hide the origin IP behind Cloudflare/WAF

    Put the system behind a WAF to block direct attacks and hide the server's real address. It is a layer that reduces risk, not a substitute for patching.

    You receiveWAF and DNS setup, with handover documentation
  6. 06

    Security Retainer

    When a new vulnerability is announced, we check whether your system is affected before you have to ask, then patch. Details in the next section.

    You receiveAlerts, a monthly report, a private channel
Two ways to start

One engagement to learn where you stand, or ongoing protection.

Most clients start with the one-time package to learn where they stand. Scope and quote are settled after a short call.

Starting point

Scan & Fix

A single engagement with a clear start and finish. It suits teams that want to know where they stand and clear the most serious problems.

You receive

  • Findings report, ranked by severity
  • Patched code, delivered as pull requests
  • Regression test report
  • Upgrade and configuration log
  • WAF and DNS setup to hide the origin IP

When it ends, the system is clean as of handover. Vulnerabilities disclosed later need the Security Retainer or a new scan.

A good fit when

  • You do not know where your system stands
  • A new vulnerability was just announced in a technology you use
  • You want the heaviest problems cleared before a partner or client asks
Ongoing

Security Retainer

Machines keep watch continuously, and engineers step in when needed. We keep the two apart so you know exactly who does what.

Machines, 24/7

  • WAF blocking direct attacks
  • Alerts on anomalies
  • Watching vulnerability announcements for the runtimes and libraries you use

Engineers, as committed

  • Critical incidents: an engineer starts work within 4 hours, nights, weekends and holidays included
  • Normal requests: handled the next business day, on the working calendar set in your contract
  • Private channel: Slack, LINE, Zalo or phone
  • Monthly report: what was blocked, what was patched, what remains
Any system can have a hole like this

Not just PHP. Also legacy systems nobody maintains.

The technologies we work with every day, and the systems that have run for years after the person who wrote them left.

PHP · Laravel · WordPressPlugins and themes included
Node.jsExpress, Next.js, npm packages
PythonDjango, FastAPI, pip
JavaSpring, Maven, Gradle
.NETASP.NET, NuGet
Legacy systemsUnmaintained, thin documentation

Old systems no one maintains

These are often the biggest risk, and the ones nobody wants to touch. We start by redrawing the picture: what the system runs, what it exposes, and what it depends on. Then we patch, and shield it with a WAF where it cannot be upgraded yet.

What we do not do

  • We do not issue independent pentest certification.
  • We do not run compliance audits (ISO 27001, PCI DSS and the like).
  • We do not do digital forensics or support legal proceedings.
  • We do not replace your SOC, EDR or workstation security.
  • We do not promise a system that is never attacked. Nobody can.

If you need certification, use an independent firm. We fix what they find.

FAQ

Questions clients ask before starting.

Do we have to hand over our source code?
To scan source code, yes, we need to read it. You only need to grant read-only access to the repository, not access to production. If you cannot share code yet, we can still review configuration and the public surface at a limited level, and we will say clearly what we could not check.
Will patching cause downtime?
Scanning does not touch production. Patches are built and tested on a separate branch or staging environment, then deployed when you choose. Putting the system behind Cloudflare usually needs no downtime. Some changes, such as a major version upgrade, may need a short maintenance window, and we tell you in advance.
What if a new vulnerability is announced tomorrow?
On the Security Retainer, we watch announcements for the runtimes and libraries you use, check whether your system is affected, and tell you. A critical incident gets an engineer's response within 4 hours, nights and weekends included. If you bought only a one-time Scan & Fix, the system is clean as of handover, and later vulnerabilities need the Security Retainer or a new scan.
What counts as a critical incident, and how are the 4 hours measured?
A critical incident is when your website or system goes down or has its content altered by an attack, when a vulnerability is being actively exploited on your system, or when there are signs of a data leak or malware. The 4 hours run from the moment an alert is raised, or you report it through your dedicated channel, to the moment an engineer starts work: blocking the attack, isolating what is affected and restoring service.
Do you replace our development team?
No. We work alongside your team. Fixes arrive as small, separate pull requests for your team to read and approve. If you want, we can help with the merge too.
How is our code kept confidential? Do you sign an NDA?
Yes. An NDA is signed before you share any source code or data, or before the first conversation if you prefer. Access is read-only, limited to the project, and revoked when the work ends. We also tell you which AI tools will read your code and use them only after you agree in writing. Patches go straight into your repository as pull requests, so every code change belongs to you.
Is hiding the IP behind Cloudflare enough?
No. A WAF blocks many direct attacks and hides the server's real address, but it reduces risk rather than replacing the patch. Some attacks can pass through if the flaw is still in the code. That is why we patch first and add the WAF as a second layer.
Do you issue pentest certification or do compliance audits?
No. We find and fix vulnerabilities, harden systems and limit the damage if an attack lands. We do not issue pentest certificates or audit ISO 27001 or PCI DSS. If you need those, use an independent firm. We are glad to fix what they report.
Where to start

Know your exposure before an attacker does.

Tell us what you run. After a short call, you receive the scope and a quote for the first scan.