DEV Community: Rokkhe

Pin your GitHub Actions by commit SHA and lock workflow permissions

Rokkhe — Sat, 14 Nov 2026 03:27:19 +0000

This article was first published on the Rokkhe blog on Hashnode. It was drafted with AI assistance and reviewed and edited by the Rokkhe team; all commands and sources were checked against GitHub's documentation.

A hands-on hardening guide for teams that already ship on GitHub Actions. 14 November 2026, Asia/Dhaka. By the Rokkhe research team.

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: How PHP2Shell Became Root on Check Point Gateways, and How to Close It

Rokkhe — Fri, 13 Nov 2026 10:03:06 +0000

Vulnerability briefing · 13 November 2026 · By the Rokkhe research team

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:

Entry. The attacker reached an internet-facing Mobile Access portal on a gateway that did not have the 23 October PHP2Shell hotfix.
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.
Root. The attacker wrote a command to the DynamicCLI socket (CVE-2026-123039), and it ran as root.
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

Install the November Jumbo Hotfix on all Management Servers and Security Gateways, starting with gateways that expose Mobile Access. The takes are listed above.
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.
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.
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

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.

DEV Community: Rokkhe

Pin your GitHub Actions by commit SHA and lock workflow permissions

TL;DR

Why a moving tag is not a pin

Pin every uses: line to a full commit SHA

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

Treat pull_request_target as a privileged event

A copy-paste starter workflow

How to audit the workflows you already have

Checklist

FAQ

Sources

Next in the series

CVE-2026-123039: How PHP2Shell Became Root on Check Point Gateways, and How to Close It

TL;DR

What is CVE-2026-123039?

Why this one matters most this week

Who is affected?

How the attack works

How to check if you're affected

How to fix it

Detection and hunting

Severity, KEV and EPSS

FAQ

References

From "patched" to "proven"

Pin every `uses:` line to a full commit SHA

Treat `pull_request_target` as a privileged event