The OWASP Top 10 is still the list most teams are asked to “cover.” The current released version is OWASP Top 10:2025. If your checklist still starts with the 2021 names, you will miss a new category (mishandling of exceptional conditions), a renamed logging item, and the fact that SSRF now sits under broken access control.

This post is a one-week, authorized testing pass of that 2025 list. It is not a penetration-test report, and it is not a licence to test anyone else’s system. Use two accounts you control, on a staging environment, with written permission if that environment is not yours alone.

TL;DR

• The official 2025 list is published at owasp.org/Top10/2025. Start there, not with a 2021 slide deck.
• Spend the first day on A01 Broken Access Control, including SSRF. That is still where most web apps fail in practice, and it is still first on the list.
• The rest of the week covers configuration, cryptography, injection, design, authentication, integrity, logging and how the app fails.
• Fix with the usual, boring controls: server-side authorization, parameterized queries, TLS, MFA, and alerts someone actually reads.
• Do not run exploit payloads against systems you do not own.

What changed in the 2025 list

OWASP’s 2025 list, in official order, is:

1. A01:2025 Broken Access Control
2. A02:2025 Security Misconfiguration
3. A03:2025 Software Supply Chain Failures
4. A04:2025 Cryptographic Failures
5. A05:2025 Injection
6. A06:2025 Insecure Design
7. A07:2025 Authentication Failures
8. A08:2025 Software or Data Integrity Failures
9. A09:2025 Security Logging and Alerting Failures
10. A10:2025 Mishandling of Exceptional Conditions

OWASP’s own project page and developer guide describe the headline shifts from 2021: SSRF is folded into A01; “vulnerable and outdated components” is broadened into software supply chain failures; and A10 is new, covering applications that fail open, leak data in errors, or leave a transaction half-applied. A09 is renamed to stress that logs only help if they raise an alert someone acts on. Security misconfiguration moves up to second.

You do not need to memorise the politics of the ranking. You need a pass you can finish.

Start with access control (A01), including SSRF

Create two ordinary users (Alice and Bob) and one admin user, all in staging. Then, with Alice’s session, try to:

• Open Bob’s object by changing an id in the URL or in a JSON body (/orders/123 → /orders/124 when 124 is Bob’s).
• Open an admin page or admin API (/admin, /api/admin/users) with Alice’s cookie or bearer token, not the admin’s.
• Call a “change role” or “change owner” endpoint as Alice.
• After logout, replay Alice’s cookie or token and see whether it still works.

A clean result is a consistent 403 or 404 from the server, not a hidden button in the browser. If the API returns Bob’s order to Alice, that is a broken access-control finding. Fix it in the service layer: every handler that loads a record by id must check that the caller is allowed to see or change that record. Do not rely on the client to hide the route.

SSRF is in this category in 2025. If your app fetches a URL that a user can influence (a webhook, a preview, an import, a “fetch metadata” field), point it at an address you control on the public internet and confirm the app cannot be steered at internal addresses such as the instance metadata service or localhost. The fix is an allowlist of schemes and hosts, plus a block on private and link-local IP ranges, applied after DNS resolution so a hostname cannot bounce you back to an internal address.

# Read response headers on a staging URL you own.
# Replace the URL. This only sends a GET.
curl -sI 'https://staging.example.invalid/account'

# Look for cookies without Secure or HttpOnly, and for missing
# security headers you have already decided to set.
curl -sI 'https://staging.example.invalid/account' | tr -d '\r' | grep -iE '^(set-cookie|strict-transport-security|content-security-policy|x-frame-options|x-content-type-options):'

If a session cookie is missing Secure or HttpOnly, fix the cookie flags before you argue about more exotic controls.

Check configuration, crypto and injection (A02, A04, A05)

A02 Security Misconfiguration is the default-on, default-password, debug-left-enabled category. On staging, confirm:

• Default accounts are disabled or their passwords are no longer the documented default.
• Debug or profiler endpoints are not reachable from the address you expose.
• Directory listing is off, and error pages do not include stack traces for anonymous users.
• TLS is required; HTTP redirects to HTTPS.

A04 Cryptographic Failures is about data at rest and in transit. Confirm the site actually negotiates a current TLS configuration, cookies that hold session material are Secure, and passwords are stored with a purpose-built password hash (see OWASP’s Password Storage Cheat Sheet), not a single SHA-256 of the password. Do not invent a home-grown cipher “for performance.”

A05 Injection is still the failure to keep data and code separate. The control is the same as it has been for years: parameterized queries, not string formatting, for SQL and for other interpreters.

# Safe pattern: the SQL stays constant, the value is a bound parameter.
# This is an illustration, not an application.
cur.execute(
    "SELECT id, email FROM users WHERE email = %s",
    (email_from_request,),
)

When you test, use only your staging database and inputs that belong to your test accounts. If you want to confirm a query is parameterized, read the code or the ORM log. You do not need a destructive payload to prove the control is missing; a code review of the query builder is enough, and it is safer.

Command injection and template injection follow the same rule: do not send untrusted input to a shell, and do not evaluate untrusted text as a template. Prefer library APIs and an allowlist of argument values.

Design, authentication and integrity (A06, A07, A08)

A06 Insecure Design is not a single test. It is the absence of a threat model for a risky feature: password reset, file upload, payment, or a new admin tool. For this week, pick the one feature that can move money or change identity. Write down the actors, what they should be allowed to do, and what happens when a step fails. If nobody can produce that paragraph, the finding is the missing design work, not a clever exploit.

A07 Authentication Failures (renamed from the 2021 “identification and authentication” title) is easier to test:

• Can you register with a clearly weak password if the product claims to block them?
• Is multi-factor authentication available for privileged users, and can it be skipped on the password-reset path?
• Does account recovery leak whether an email is registered, in a way you did not intend?
• Are session IDs rotated after login, and invalidated at logout?

Use only accounts you created for the test. Do not run a password spray against a real user population.

A08 Software or Data Integrity Failures covers unsigned updates, CI artefacts you do not verify, and insecure deserialization of untrusted data. For a web app this week: confirm the production image or tarball you deploy is the one the pipeline built (a digest, not a floating latest tag), and that you do not deserialize attacker-controlled bytes into application objects. Post 1 in this series covers a related control in GitHub Actions.

Logging, alerting and exceptional conditions (A09, A10)

A09 is no longer only “we have logs.” The 2025 name is Security Logging and Alerting Failures. For each of the tests above that should fail (Alice opening Bob’s order, a rejected login), check that a log line exists with a time, a user id, a resource id, and a result, and that something would page a human if the same failure repeated. A log no one reads is not a control.

A10 Mishandling of Exceptional Conditions is new. It is the app that returns a stack trace, that “fails open” when the authorization service times out, or that credits an account twice when a downstream call errors halfway. For this week:

• Trigger a 404 and a 500 on staging and read the response body as an unauthenticated user. It should not include stack traces, internal hostnames or connection strings.
• If you have a multi-step action (pay, provision, invite), abort it in the middle and check that you cannot be left in an authorized state the design did not intend.

# Authorized request against your staging app: look at an error body.
curl -sS -D - 'https://staging.example.invalid/this-route-should-not-exist' -o /tmp/body.txt
head -c 500 /tmp/body.txt

If the body contains exception names, file paths or SQL, fix the error handler so users get a generic message and the detail stays in a log.

Supply chain failures (A03) without repeating post 1

A03 in 2025 is broader than “run npm audit once.” It includes third-party dependencies, build tools, and how updates are delivered. For this week, do the minimum that is still useful:

• Generate a lockfile (package-lock.json, poetry.lock, go.sum, Cargo.lock) and commit it.
• Run the package manager’s audit command in CI and actually assign the findings.
• Pin CI Actions by SHA if you have not already (see post 1).

# Examples. Run the one that matches the repo, in a clone you own.
npm audit --omit=dev
pip-audit
go list -m all

Do not treat a raw count of audit findings as a severity ranking. Post 4 in this series is about prioritizing CVEs with KEV, EPSS and CVSS.

A one-week testing checklist

Day 1 — A01. Two-user object tests, admin-route tests, token replay, and a first look at any user-controlled URL fetch.

Day 2 — A02 and A04. Defaults, debug endpoints, TLS, cookie flags, password storage, data in transit.

Day 3 — A05 and A08. Parameterized queries, template and command sinks, deploy-artefact integrity.

Day 4 — A07 and A06. Authentication, reset, session rotation, and a one-page threat note for the riskiest feature.

Day 5 — A09, A10 and A03. Logs and alerts for the failed tests, error-page review, lockfile and audit command, then a short write-up of what you fixed.

Write findings down as: category, where, how you tested (authorized), what you changed, how you retested. That is enough to be useful next month.

FAQ

Is this a full penetration test? No. It is a structured self-test of the 2025 Top 10 on an application you are allowed to test. A penetration test can go further, under a written scope.

Should we still use the 2021 list? The current released version is 2025. Keep historical reports labelled as 2021 if that is what they used, but new work should follow the 2025 categories.

Where do I put SSRF on a ticket? Under A01:2025 Broken Access Control, which is where the 2025 list places it.

Can we automate all of this? You can automate header checks, dependency audits and some access-control tests. Authorization still needs cases that only a person who understands the product can invent. Automate the boring checks; do not skip Day 1.

We already have a scanner. Is this redundant? A scanner is a useful input. It does not replace the two-user access-control pass or the “does this error fail open?” check.

Sources

• OWASP, OWASP Top 10:2025
• OWASP, Top 10 project page
• OWASP Developer Guide, OWASP Top 10
• OWASP Cheat Sheet Series, Password Storage Cheat Sheet

Next in the series

Next up: Find leaked secrets in Git and rotate them before they are used.

Rokkhe is an AI pentesting and security-operations workspace. Learn more at rokkhe.com.

A tag like @v6 is convenient, and it is also movable. Anyone who can push a new commit to that tag can change the code your workflow runs the next time the tag is resolved. The same workflow often also hands the job a GITHUB_TOKEN that can write to the repository. Those two defaults — a movable pointer and a write-capable token — are what this post closes.

You will leave with three things: every uses: line pinned to a full 40-character commit SHA, a workflow that starts from read-only permissions, and a short list of pull_request_target mistakes to avoid. All of the commands below are read-first. None of them changes a GitHub setting until you choose to apply the YAML.

This is the first post in a ten-part how-to series. It is the only CI/CD-focused guide in the set. Later posts cover the OWASP Top 10, secrets, CVE triage, cloud and Kubernetes hardening, API and LLM-app security, an AI review harness, and Sigma rules.

TL;DR

• Pin third-party Actions, and your own reusable workflows, to a full commit SHA, not a tag or branch. GitHub’s own documentation tells you to do this.
• Put a permissions: block at the top of every workflow so the default GITHUB_TOKEN is read-only, then grant extra scopes on the job that needs them.
• Treat pull_request_target as a privileged event: it runs in the base repository’s context and can see secrets. Do not check out and run untrusted pull-request code in that workflow.
• Audit what you already have before you change production deploy workflows. The commands below only read.

Why a moving tag is not a pin

An Action is just a Git repository. When a workflow says:

- uses: actions/checkout@v6

GitHub resolves v6 to whatever commit that tag currently points at. Tags are not immutable. A tag can be deleted and recreated, or force-moved, so the same @v6 on Monday is not guaranteed to be the same code on Tuesday.

A full Git commit SHA names one object. This is the form GitHub documents for pinning:

- uses: actions/checkout@d23441a48e516b6c34aea4fa41551a30e30af803 # v6.1.0

The SHA above is an example of the form: it is what the v6.1.0 tag of actions/checkout resolved to when we checked on 14 November 2026. Before you paste any SHA into a production workflow, resolve it yourself from the Action’s official repository, as shown in the next section. Do not copy SHAs from a blog post and assume they are still the latest release.

Pinning does not mean “never update.” It means updates become a deliberate pull request: a new SHA, a comment with the version, and a review. That is the point. You want the change to be visible.

Pin every uses: line to a full commit SHA

Work in a branch. For each Action, resolve the tag you intended to use to a 40-character SHA from the official repository, not a fork.

# Example only: resolve a tag on the official actions/checkout repo.
# Replace the URL and tag with the Action you actually use.
git ls-remote https://github.com/actions/checkout.git refs/tags/v6.1.0

You want the peel to a commit, not an annotated-tag object. If the command prints both a tag object and a peeled commit (^{}), take the commit:

git ls-remote --tags https://github.com/actions/checkout.git 'v6.1.0*'

Confirm the commit is on the official repo in the browser: https://github.com/OWNER/ACTION/commit/THE_SHA. Then write the pin with the human-readable version in a comment, which GitHub’s documentation encourages so reviewers can see what you meant:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Check out the repository
        uses: actions/checkout@d23441a48e516b6c34aea4fa41551a30e30af803 # v6.1.0

Apply the same rule to reusable workflows:

jobs:
  call-shared:
    uses: octo-org/common/.github/workflows/build.yml@FULL_40_CHAR_SHA

A branch name (@main) or a moving major tag (@v2) on a uses: line is not a pin. Abbreviated SHAs are also the wrong form; GitHub asks for the full length.

If you use Dependabot or a similar updater, configure it to open pull requests that bump the SHA and the comment together. The pin is only useful if the update path is boring.

Set default workflow permissions to read-only, then grant per job

The GITHUB_TOKEN is created automatically for each job. GitHub’s guidance is to grant it the minimum permissions the job needs, and to set the default for repository contents to read-only. The clean way to do that in the workflow file is an explicit top-level block:

name: CI

on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@d23441a48e516b6c34aea4fa41551a30e30af803 # v6.1.0
      - run: make test

When a job must write, raise the scope on that job only:

jobs:
  release:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      id-token: write
    steps:
      - uses: actions/checkout@d23441a48e516b6c34aea4fa41551a30e30af803 # v6.1.0
      # publish steps go here

id-token: write is not a repository-write grant. It only lets the job request an OIDC token for a cloud exchange. That is expected if you later move off long-lived cloud keys, but it should still be limited to the job that talks to the cloud.

Also set the repository (or organization) default in the GitHub UI so a workflow file that forgets permissions: does not silently get a write token: Settings → Actions → General → Workflow permissions → Read repository contents and packages permissions. The YAML block is still required, because it is reviewed with the code.

Do not use permissions: write-all. If you see it in a copied example, delete it.

Treat pull_request_target as a privileged event

pull_request runs in the context of the merge commit and, for a fork, with a restricted token and no secrets. pull_request_target is different. GitHub’s documentation is explicit: the workflow runs in the base repository’s context, with the base repository’s GITHUB_TOKEN and access to secrets. That is what makes it useful for labelling or commenting on pull requests from forks. It is also what makes it dangerous.

The safe pattern is: the workflow file, and any actions/checkout that does not pass an explicit ref, come from the default branch of the base repository. Untrusted code from the pull request is not executed.

The unsafe pattern, which GitHub and the GitHub Security Lab have both warned about, is to check out the pull request’s untrusted ref and then run its install or test scripts in that same privileged job:

# Unsafe pattern — do not use this.
# It is shown only so you can recognise it in a review.
on:
  pull_request_target:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@d23441a48e516b6c34aea4fa41551a30e30af803 # v6.1.0
        with:
          ref: ${{ github.event.pull_request.head.sha }}
      - run: npm install && npm test   # this runs untrusted code with base secrets

If you need to comment on a fork pull request, keep the privileged job small: no checkout of the head SHA, no npm install of the head branch, no running of the contributor’s Makefile. Use a pull_request workflow for tests, and a tightly scoped pull_request_target workflow only for authentication-needed comments, with permissions limited to pull-requests: write.

Two newer guardrails are worth knowing. GitHub now applies a default Actions event policy that blocks pull_request_target in public repositories that have no event policy of their own. It currently runs in evaluate mode, and GitHub says it will enforce it on 2 December 2026, so check your policy insights now if you rely on this event. Recent versions of actions/checkout also refuse to check out a fork's pull-request head in this context unless you set allow-unsafe-pr-checkout: true. Treat that flag as a review red flag: only set it when the checked-out code is read as data and never executed.

GitHub also documents cache behaviour for this event: pull_request_target workflows get read-only access to the default branch’s cache, unless you opt into a writeable cache mode, which reintroduces cache-poisoning risk. Leave the default alone.

A copy-paste starter workflow

Use this as a starting point for a private or public repository that runs tests on pull requests. Resolve the checkout SHA yourself before you merge it.

name: CI

on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Check out
        uses: actions/checkout@d23441a48e516b6c34aea4fa41551a30e30af803 # v6.1.0

      - name: Run tests
        run: |
          set -euo pipefail
          if [ -f Makefile ]; then
            make test
          elif [ -f package.json ]; then
            npm ci
            npm test
          else
            echo "Add the test command for this repository."
            exit 1
          fi

There is no pull_request_target here, no write-all, and no secrets. Add deploy jobs in a separate workflow, on a trusted event such as push to main or a release, with job-level permissions and an environment that requires a reviewer if the job can touch production.

How to audit the workflows you already have

These commands only read the files on disk. Run them in a clone of the repository.

List every workflow and every uses: line that is not pinned to a 40-character SHA:

# From the repository root.
find .github/workflows -type f \( -name '*.yml' -o -name '*.yaml' \) -print

# uses: lines that do not end in a 40-character hex SHA (tags, branches, short SHAs).
grep -nE 'uses:' .github/workflows/*.{yml,yaml} 2>/dev/null \
  | grep -vE 'uses:[[:space:]]*[^@]+@[0-9a-f]{40}([[:space:]]|#|$)'

List workflows that never set permissions::

for f in .github/workflows/*.{yml,yaml}; do
  [ -f "$f" ] || continue
  if ! grep -qE '^[[:space:]]*permissions:' "$f"; then
    printf 'No permissions block: %s\n' "$f"
  fi
done

List pull_request_target workflows so a person can review them:

grep -n 'pull_request_target' .github/workflows/*.{yml,yaml} 2>/dev/null

On GitHub, also open Actions → workflow run logs after a test change and confirm secrets are redacted, as GitHub recommends in its secure-use reference. If a secret ever appears in a log, delete that log and rotate the secret. Finding a leak is the subject of post 3 in this series.

Checklist

• Every uses: line, including reusable workflows, pins a full 40-character SHA from the official repository.
• A version comment sits next to each SHA so reviewers can see the intended release.
• Each workflow file has a top-level permissions: block; the default is contents: read.
• Write scopes are granted only on the job that needs them, never with write-all.
• The repository (or organization) default workflow permission is also read-only.
• pull_request_target is used only when a base-repository token is required, and that job does not check out and execute untrusted head code.
• Deploy jobs use a GitHub Environment with required reviewers when they can reach production.
• An updater (Dependabot or equivalent) can open PRs that bump the SHA and the comment together.
• Someone has grepped the existing workflows with the audit commands above.
• If a secret was ever printed in a log, that log was deleted and the secret was rotated.

FAQ

Is pinning to @v6.1.0 (an exact tag) good enough? No. An exact tag is more stable than @v6, but the tag can still be moved. GitHub’s documented pin is the full commit SHA, with the tag in a comment.

Does a SHA pin mean we are stuck on an old Action? No. You update by changing the SHA in a pull request, the same way you update any other dependency. The difference is that the update is reviewed, not silent.

Can we pin to a short SHA? Do not. Use the full 40-character object name.

We need to comment on pull requests from forks. Must we use pull_request_target? Often yes, because a privileged token is required to comment. Keep that workflow small, grant only pull-requests: write, and do not run the contributor’s build in that job.

Will this break Dependabot? Only if Dependabot is not configured to update Actions. Once it is, it should open PRs that retarget the SHA. Review those PRs the way you review application bumps.

Sources

• GitHub Docs, Using pre-written building blocks in your workflow
• GitHub Docs, Secure use reference
• GitHub Docs, Securely using pull_request_target
• GitHub Docs, Use GITHUB_TOKEN for authentication in workflows

Next in the series

Next up: Test and fix the OWASP Top 10 2025 in your web app this week.

Rokkhe is an AI pentesting and security-operations workspace. Learn more at rokkhe.com.

CVE-2026-123039 is a high-severity (CVSS 7.8) privilege escalation in the DynamicCLI service of Check Point Gaia OS. On 12 November 2026, Check Point confirmed that attackers chained it with PHP2Shell in the Mobile Access portal to gain root on unpatched gateways. Install the November Jumbo Hotfix, then hunt for the published indicators.

TL;DR

• What: a root process on Gaia (dynamic_server) accepts commands from a world-writable local socket without checking who is connecting. Anyone already running code on the box can become root.
• How it was used: PHP2Shell (CVE-2026-109618 / CVE-2026-109619) gave the attacker code execution through the Mobile Access portal. CVE-2026-123039 turned that into root.
• Who: Check Point Force Firewalls, Management and Log Servers, Multi-Domain servers and Maestro Orchestrator on R81 to R82.20. Spark Firewalls and Smart-1 Cloud are not affected by CVE-2026-123039.
• Exploited? Yes. Check Point saw the chain used against "a couple of dozen" unpatched systems between 30 October and 4 November 2026.
• Fix: November Jumbo Hotfix: R82.20 Take 14, R82.10 Take 52, R82 Take 132 or R81.20 Take 174 or later.
• Then: patching closes the door, but it does not remove an attacker who is already inside. Hunt before you call it done.

What is CVE-2026-123039?

Gaia's dynamic (extended) CLI is served by a root process called dynamic_server. It listens on a local socket at /tmp/dynamic_socket. According to Check Point's advisory (sk1000362), on affected versions that socket is created world-writable (0777), the connecting process is not authenticated, and the daemon runs whatever command string it receives as root.

On its own, this is a local bug: CVSS 3.1 vector AV:L/AC:L/PR:L/UI:N, score 7.8. An attacker first needs to run code on the appliance. That is exactly what PHP2Shell provides.

Why this one matters most this week

We weighed everything disclosed or newly exploited from 11 to 13 November, including a critical Apache HTTP Server mod_http2 bug (CVE-2026-119618) and a large Citrix NetScaler patch set. Neither had confirmed in-the-wild exploitation when we checked. This chain does. It hits the security gateway itself, the device that sits at the edge of the network and holds VPN access and the firewall policy. In some of the incidents the attackers also reached a hypervisor.

Who is affected?

CVE-2026-123039 (local privilege escalation, sk1000362):

• Products: Check Point Force Firewalls; Management and Log Servers; Multi-Domain Security Management and Multi-Domain Log Server; Maestro Orchestrator.
• Affected versions: R82.20, R82.10, R82, R81.20, plus R81.10 and R81 (both end of support).
• Not affected: Check Point Spark Firewalls and Smart-1 Cloud.

PHP2Shell on Check Point (remote code execution, sk1000302). This applies to firewalls that use any of these features:

• Mobile Access Portal
• Remote Access VPN with SSL Network Extender
• Remote Access VPN with SAML realm authentication
• Identity Awareness Captive Portal
• UserCheck Portal
• Zero Phishing

Affected versions are R81.20 to R82.20, older end-of-support releases from R80, and Spark R81.10.x and R82.00.x. Security Management and Log Servers are not affected by PHP2Shell.

Fixed versions (both issues):

• R82.20: Jumbo Hotfix Take 14 or later
• R82.10: Jumbo Hotfix Take 52 or later
• R82: Jumbo Hotfix Take 132 or later
• R81.20: Jumbo Hotfix Take 174 or later
• Spark R82.00.11: build B998002843 or later
• Spark R81.10.17: build B996005005 or later

How the attack works

This is how Check Point Research described the intrusions, in plain terms:

1. Entry. The attacker reached an internet-facing Mobile Access portal on a gateway that did not have the 23 October PHP2Shell hotfix.
2. Code execution. PHP2Shell, a use-after-free class of flaws in PHP request handling, gave them code execution as the portal's service account. Check Point found PHP session files containing the marker upload_progress_pwn, and hundreds of crashes in the portal's web workers.
3. Root. The attacker wrote a command to the DynamicCLI socket (CVE-2026-123039), and it ran as root.
4. Persistence and pivot. They planted PHP webshells as zz*.tpl templates in the portal, and a backdoor disguised as CPconfigdaemon that later runs as slot_CPconfigdaemon and drops /lib/libcpfwcommon.so. They scanned the internal network, moved over SSH to a VMware ESXi host using the vpxuser account, and in a limited number of cases ran a wiper.

Check Point says a first wave on 30 October focused on organisations in one region (Israel). A second wave on 2 November scanned organisations in several countries, with no evidence of destructive activity. Check Point also says the evidence does not support a high-confidence attribution.

How to check if you're affected

Run these on every gateway, cluster member and management server. Use Expert mode unless noted. All of them only read; none changes anything.

• Version and Jumbo take: run show version all in clish, or cpinfo -y all in Expert mode and read the JUMBO_HF_MAIN take. Compare it with the fixed takes above.
• Exposure to PHP2Shell: enabled_blades lists the active blades. Look for Mobile Access and Identity Awareness, then check in SmartConsole which portals face the internet.
• The vulnerable socket: ls -l /tmp/dynamic_socket. A world-writable socket (srwxrwxrwx) on an unpatched take matches the advisory's description.
• After patching: grep "Rejected connection from unauthorized uid" /var/log/dynamicCli.log. The fix blocks and logs unauthenticated calls, so hits here are worth a closer look.

How to fix it

1. Install the November Jumbo Hotfix on all Management Servers and Security Gateways, starting with gateways that expose Mobile Access. The takes are listed above.
2. If you cannot patch PHP2Shell today, apply the cp-httpd.conf mitigation in sk1000302 and restart the portals. Check Point also offers a standalone PHP2Shell hotfix, which needs a reboot. R82.20 gateways are protected by the IPS signature "PHP Remote Code Execution", even when IPS is not enabled.
3. If you cannot patch CVE-2026-123039 today, follow the sk1000362 mitigation, which stops the dynamic_server process and keeps it from restarting. This breaks the Dynamic CLI commands listed in sk144112.
4. Retest from the outside. Confirm the portals respond as expected and the take is correct on every cluster member, not just the active one.

Detection and hunting

Check Point notes that no match does not rule out compromise. On the other hand, any match calls for immediate investigation.

On the appliance (read-only):

• grep -rl upload_progress_pwn /opt/CPcvpn-*/tmp/ 2>/dev/null finds PHP session artefacts from the exploit.
• find / -xdev \( -name 'zz*.tpl' -o -name '.up.tpl' \) 2>/dev/null finds the webshell templates.
• ls -la /tmp/CPconfigdaemon /tmp/.bd.log /tmp/.p_sock /lib/libcpfwcommon.so 2>/dev/null checks for backdoor files.
• ps -ef | grep -i '[C]Pconfigdaemon' and netstat -tlnp | grep ':11072' check for the backdoor process and its listener.
• Check SHA-256 hashes of anything suspicious against the IOC table in Check Point Research's report.

In your SIEM:

• Splunk: index=* ("130.94.19.204" OR "130.94.19.168")
• Microsoft Sentinel: CommonSecurityLog | where SourceIP in ("130.94.19.204","130.94.19.168") or DestinationIP in ("130.94.19.204","130.94.19.168")
• SSH logins to ESXi hosts as vpxuser that come from a gateway address.
• Gaps in firewall traffic logs, especially after the logging daemon crashes.

If you find a match, treat the gateway as compromised. Bring in Check Point support and your incident-response process, preserve evidence, and rotate the credentials that pass through or are stored on the gateway.

Severity, KEV and EPSS

• CVE-2026-123039: CVSS 3.1 7.8 (High), assigned by Check Point as the CNA. NVD analysis is pending. Check Point and the Canadian Centre for Cyber Security (AV26-1154) report it as exploited in the wild. It was not yet in CISA's KEV catalog when we checked on 13 November (catalog version 2026.11.10), and FIRST has not yet published an EPSS score for it.
• PHP2Shell (CVE-2026-109618 / CVE-2026-109619): CVSS 9.2 (Critical). It has been in CISA KEV since 26 October 2026, with a federal due date of 29 October. Its EPSS score on 12 November was 0.99999, the top of the scale.

FAQ

What is CVE-2026-123039? It is a local privilege escalation in Check Point Gaia OS. The root dynamic_server process accepts commands from a world-writable socket without authentication, so anyone already running code on the appliance can become root. CVSS 7.8.

Is CVE-2026-123039 being exploited? Yes. Check Point confirmed exploitation, chained with PHP2Shell, against a couple of dozen unpatched systems between 30 October and 4 November 2026.

Which Check Point versions fix it? The November Jumbo Hotfix fixes it: R82.20 Take 14, R82.10 Take 52, R82 Take 132 and R81.20 Take 174 or later. R81 and R81.10 are end of support, so plan an upgrade.

My gateway doesn't use Mobile Access. Am I safe? You are less exposed, but not safe. PHP2Shell also reaches gateways through SSL Network Extender, SAML VPN, Captive Portal, UserCheck and Zero Phishing. CVE-2026-123039 also affects management servers. Patch everything.

I patched. Am I done? Not yet. Patching stops new break-ins. Hunting for the indicators above shows whether someone got in before you patched.

References

• Check Point Blog: Security Advisory: Active Exploitation of PHP2Shell and Local Privilege Escalation (12 Nov 2026)
• Check Point Research: PHP2Shell Exploitation on Check Point Gateway (12 Nov 2026)
• Check Point sk1000362: CVE-2026-123039
• Check Point sk1000302: PHP2Shell response
• NVD: CVE-2026-123039
• Canadian Centre for Cyber Security AV26-1154
• CISA Known Exploited Vulnerabilities catalog
• PHP security advisory GHSA-6wmf-4rv5-p3rp
• FIRST EPSS
• cve.now

From "patched" to "proven"

Attackers struck about a week after the fix shipped, and they chained two bugs: one at the edge, one on the box. Most teams found out about the second one only this week. That gap is the job.

This briefing was written by the Rokkhe research team. Rokkhe is an AI pentesting and security-operations workspace. Learn more at rokkhe.com.