Lagoon CVE-2026-113788: Authenticated RCE in the SSH Service

CVE-2026-113788 is a critical command injection flaw (CWE-78, CVSS 4.0 score 9.4) in the ssh service of Lagoon core, the open source application delivery platform for Kubernetes. Anyone holding a Lagoon user account could use it to run arbitrary code and gain elevated administrative permissions. Every Lagoon version before 2.33.2 is affected, including 2.33.1. Upgrade to Lagoon 2.33.2 (Helm chart lagoon/lagoon-core 1.62.2) or later, or disable the ssh service until you can.

The fix has been public since 25 August 2026, when the Lagoon maintainers released 2.33.2 and published a GitHub security advisory. The CVE record itself only reached the National Vulnerability Database on 21 October 2026. That gap of about eight weeks is the real story for platform teams: if you learn about vulnerabilities from CVE feeds alone, you heard about this one late, and if you do not know which Lagoon version each of your clusters runs, you cannot answer the first question anyone will ask. This post covers what the flaw is, how to read its score, how to check your own clusters, how to fix or work around it, and where software inventory and policy gates help.

Key takeaways

• Affected: every Lagoon release earlier than 2.33.2. The CVE description says "prior to 2.33.1", but the structured data in the same record and the advisory both say versions below 2.33.2 are affected. 2.33.1 has no security fix. Treat it as vulnerable.
• Fixed: Lagoon 2.33.2, shipped in the lagoon/lagoon-core Helm chart 1.62.2 on 25 August 2026. Later releases such as 2.34.0 (chart 1.63.0) are outside the affected range.
• Precondition: the attacker needs a Lagoon user account.
• Exploitation: none reported in the sources we checked. CISA's SSVC assessment on 23 October recorded exploitation "none", automatable "no" and technical impact "total". The CVE is not in the CISA Known Exploited Vulnerabilities catalog as of the 26 October 2026 catalog release.
• Detection hint: the advisory says exploitation may show up in the ssh service container logs as too many arguments. A clean log is not proof of safety.
• Workaround: disable the ssh service in Lagoon core. The newer ssh-portal service and its components are not affected.

What happened, and why it is a 9.4 with an asterisk

Lagoon's maintainers published GitHub security advisory GHSA-f8mw-q232-qjfp, titled "Remote code execution via Lagoon core ssh service", on 25 August 2026. The advisory states that a vulnerability in the ssh service in Lagoon core "would allow an attacker to execute arbitrary code", which could lead to elevated administrative permissions among other things. On the same day they released Lagoon 2.33.2, whose release notes open with a plain line: the release "fixes a critical security vulnerability" and upgrading as soon as possible is recommended.

The CVE identifier CVE-2026-113788 was assigned by GitHub as the CVE Numbering Authority. NVD published the record on 21 October 2026 at 16:17 UTC and last modified it on 23 October, when CISA added its SSVC decision points. As of 27 October the NVD status is "Awaiting Analysis", which means NVD has not yet added its own score or product configuration data. The 9.4 you see everywhere comes from the GitHub CNA.

The score reflects impact: code execution inside a service that brokers shell access to every environment Lagoon manages. The qualification is the precondition. The advisory says the risk "is mitigated by the fact that an attacker must have a Lagoon user account". CVSS 4.0 captures that as Privileges Required: Low. It does not reduce the score much, because a low privilege account is still something many people have.

So the asterisk is not "this is fine". It is "would you trust every Lagoon account holder with cluster level code execution?" On a hosting platform with customer, agency or contractor accounts, the answer is almost certainly no.

Timeline from primary sources

Two dates matter most. On 25 August any team tracking Lagoon releases could patch. On 21 October most scanners and dashboards first had an identifier to match. Anyone still below 2.33.2 has carried a known, fixable critical flaw for about nine weeks.

What Lagoon is, and where the ssh service sits

Lagoon describes itself as "the Open Source Application Delivery Platform for Kubernetes". Developers describe their services in YAML files (a .lagoon.yml and a docker-compose.yml), push to Git, and Lagoon builds the Docker images, pushes them to a registry, creates the Kubernetes resources and monitors the rollout.

A Lagoon installation has two halves, each shipped as its own Helm chart:

• Lagoon core (lagoon/lagoon-core) holds the control plane: the API and its database, Keycloak for identity, the webhook handler, the UI, the message broker and several SSH related services.
• Lagoon remote (lagoon/lagoon-remote) runs in each Kubernetes cluster that hosts customer environments. One core can manage several remote clusters.

The legacy ssh service

Lagoon's SSH documentation explains the model clearly. Application containers do not run an SSH server. Instead, "you connect via SSH to Lagoon, which then itself creates a remote shell connection via the Kubernetes API for you." The SSH username encodes the target, in the form project-environment, and extra arguments such as service= and container= select which pod and container you land in. The docs give a connection string example of the form ssh -t -p 32222 projectname-environment@ssh.lagoon.example.com.

That broker is the ssh service in Lagoon core, the component this CVE is about. In the lagoon-core chart its values block sets ssh.enabled: true by default, runs two replicas, and uses the image repository uselagoon/ssh with a tag that defaults to the chart's appVersion. In other words, a default core install runs this service, and its image tag tracks the Lagoon release.

To open a shell in any environment for any authorized user, this service needs access to the Kubernetes API of the clusters Lagoon manages and to the Lagoon API for key and permission checks. That concentration of access is why a code execution flaw here reaches past a single environment.

The newer ssh-portal services

The Lagoon project also maintains a separate repository, lagoon-ssh-portal, with three SSH services:

• ssh-portal runs in each Lagoon remote cluster and gives shell access to environments in that cluster only. It asks Lagoon core whether a key is valid for the requested environment.
• ssh-portal-api runs in Lagoon core and answers those authentication and authorization questions. Its README calls it explicitly not a public API.
• ssh-token runs in Lagoon core and returns Lagoon API tokens to users who authenticate with their SSH key. It does not provide shell access.

The README notes that ssh-portal implements shell access with service and container selection but "does not implement token generation", which is why ssh-token exists alongside it. Communication between the pieces runs over NATS, with mutual TLS between remote leaf nodes and the core cluster. In the current charts these services are switched off by default: sshPortal.enabled: false in lagoon-remote, and sshPortalAPI.enabled: false and sshToken.enabled: false in lagoon-core.

The advisory states that "the ssh-portal service and components are not effected and can continue to be used". That matters for the workaround, which we cover below.

The flaw: CWE-78 and how to read the score

CWE-78 in plain terms

CWE-78 is "Improper Neutralization of Special Elements used in an OS Command", better known as OS command injection. It happens when software builds an operating system command from input that an outside party controls and fails to keep that input from being read as part of the command itself. The classic results are extra commands, extra arguments or changed program behaviour, all running with the privileges of the vulnerable process.

An SSH broker is a natural place for this class of bug. It receives a username, a command string and arguments such as service=cli from the client, and must turn them into a Kubernetes exec call or a shell invocation. Every piece of that input comes from the person connecting.

What the sources say about root cause, and what they do not

The advisory and the CVE record do not describe the vulnerable code path, and we will not guess at one. Two facts in the public record are worth noting with care:

• The detection hint is that the ssh service logs may contain the string too many arguments when exploitation is attempted. That fits a flaw in how arguments are parsed or passed, but the advisory does not say more.
• The 2.33.2 release notes list three code changes. One is titled "reject ssh usernames that can't map to a namespace" (pull request 4153). The advisory does not say which change fixes the CVE, so we do not claim that this is the fix. It does tell defenders that 2.33.2 changed how the ssh service validates usernames, which is useful context if you maintain your own patches or forks of Lagoon.

What we do not know yet. No source we checked reports exploitation in the wild or a public exploit. CISA's SSVC entry records exploitation as "none". The advisory does not publish the root cause, the exact vulnerable function or proof of concept details, and we do not provide any. We also do not know how many Lagoon installations still run affected versions. If any of this changes, the advisory and the NVD record are the places it will show first.

The CVSS 4.0 vector, metric by metric

The GitHub CNA scored the flaw CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H, base score 9.4, CRITICAL. Here is what each part means for this specific service.

The subsequent system metrics are the part people skim past. CVSS 4.0 splits impact on the vulnerable component from impact on downstream systems. Rating all three subsequent impacts High says the scorer expects a compromised ssh service to expose other systems, which matches the service's job as a shell broker into every environment.

The base score has no threat or environmental metrics; Exploit Maturity is "Not Defined". If you adjust for your environment, the real lever is who holds accounts. Do not lower urgency to zero on that basis: accounts get phished and offboarding lags.

How CISA's SSVC entry reads

CISA's Stakeholder Specific Vulnerability Categorization (SSVC) uses decision points rather than a single number. For this CVE CISA recorded exploitation none (no evidence of active exploitation or a public proof of concept), automatable no and technical impact total (full control of the affected software). CISA does not publish its reasoning in the record, so we do not read more into the combination than the three values. Our reading as a platform owner: the fix has been out for about nine weeks, so it belongs on this week's schedule, not next quarter's.

"Prior to 2.33.1" versus "below 2.33.2": why 2.33.1 is still vulnerable

The CVE description says "Versions prior to 2.33.1 have a vulnerability". Read alone, that sentence suggests 2.33.1 is safe. It is not, and the same record shows why:

1. The structured affected data in the NVD record, supplied by the same CNA, lists the product as affected for versions below 2.33.2.
2. The GitHub advisory lists affected versions as below 2.33.2 and the patched version as 2.33.2.
3. The 2.33.1 release notes, dated 31 July, contain no security fix. The 2.33.2 release notes are the ones that say "fixes a critical security vulnerability", and Lagoon's docs say 2.33.2 supersedes 2.33.1.
4. The description itself says "The vulnerability was fixed in Lagoon v2.33.2".

The "prior to 2.33.1" phrase is a wording slip in the prose. The rule to apply is simple: any Lagoon core earlier than 2.33.2 is vulnerable, 2.33.1 included. Tools that parse the structured range should get this right. Humans reading the summary text, and any tool that extracts version ranges from prose, may not. If an internal ticket or dashboard says "fixed in 2.33.1", correct it.

Who is exposed

You are in scope if you operate Lagoon core yourself and run a version before 2.33.2 with the default ssh service enabled. The flaw lives in Lagoon core, so the question is about your core install, not about each remote cluster or each application.

The threat model for a low privilege account

In a typical install, Lagoon accounts belong to your own developers, agency and contractor developers added per project (and not always removed when it ends), customer developers on a hosting platform, and automation accounts used by CI jobs. Lagoon's role based access control is meant to keep each of them inside their own projects. A flaw that turns any of those accounts into code execution in the shared broker breaks that separation. On a multi tenant hosting platform, that is a tenant isolation failure. On a single company platform, it is an insider and stolen credential problem. Either way, who holds accounts and how quickly they are removed becomes part of your vulnerability response.

Am I running an affected version?

The commands below are templates, not a verified recipe. Every release name, namespace, kube context, pod name pattern, file path and registry host in them (lagoon-core, clusters/prod/..., registry.example.com, $REGISTRY_USER) is a placeholder you must replace with your own. They were written from the Lagoon documentation and chart values and have not been run against your environment, so test them on a non production core first.

They assume a core install in the lagoon-core namespace with a Helm release named lagoon-core, which is the layout Lagoon's update documentation uses. Adjust names to your environment. All of these commands only read state.

1. Find the chart and app version Helm thinks is installed

# List Helm releases in the core namespace; the CHART column shows lagoon-core-<version>
# and APP VERSION shows the Lagoon release, for example v2.33.1
helm list --namespace lagoon-core

# Machine readable, useful for scripts and for many clusters
helm list --namespace lagoon-core --output json | jq -r '.[] | "\(.name) \(.chart) \(.app_version)"'

You want to see chart lagoon-core-1.62.2 or later and app version v2.33.2 or later. Chart 1.62.2 is the first lagoon-core chart that ships the fix; its Chart.yaml sets appVersion: v2.33.2.

If you run several Lagoon cores, for example separate staging and production platforms, run this against each kube context:

for ctx in $(kubectl config get-contexts -o name); do
  echo "== $ctx"
  helm list --kube-context "$ctx" --all-namespaces --filter 'lagoon-core' --output json \
    | jq -r '.[] | "\(.namespace) \(.name) \(.chart) \(.app_version)"'
done

2. Confirm the image tag that is actually running

Helm metadata shows what was installed, not what runs if someone pinned an older tag or deployed from a fork. Check the pods:

# Show every container image in the core namespace that comes from the ssh repository
kubectl get pods --namespace lagoon-core \
  -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' \
  | grep -i 'uselagoon/ssh'

# Check whether the values in use override ssh.image.tag
helm get values lagoon-core --namespace lagoon-core --all | yq '.ssh'

If the running tag, or a pinned tag in values, is earlier than v2.33.2, you are affected whatever the chart version says. For images from your own registry or a fork, check which upstream commit they were built from.

3. Check whether the ssh service is enabled at all

# Is the legacy ssh service deployed?
kubectl get deployments,services --namespace lagoon-core | grep -E 'ssh'

# Is it switched on in values? (true is the chart default)
helm get values lagoon-core --namespace lagoon-core --all | yq '.ssh.enabled'

You will typically see separate objects for ssh, and, if you enabled them, ssh-portal-api and ssh-token. Only the legacy ssh service is affected.

4. Look for the log string the advisory names

The advisory says exploitation "may be detected by checking the container logs of the ssh service for: too many arguments". Check every replica:

# Find the ssh pods, then search each one's logs
for p in $(kubectl get pods --namespace lagoon-core -o name | grep -E '/lagoon-core-ssh-[a-z0-9]+-[a-z0-9]+$'); do
  echo "== $p"
  kubectl logs --namespace lagoon-core "$p" --all-containers --timestamps \
    | grep -n 'too many arguments' || echo "no match in current logs"
done

The pod name pattern in the loop above is a placeholder; adjust it to match your release and namespace. If you ship container logs to a central store, which Lagoon's logging documentation describes, search there instead and go back to at least 25 August, ideally further. Pod logs on the node rotate, and a pod that restarted or was rescheduled has lost its earlier logs.

Treat the result carefully:

• A match is a strong reason to start incident response: preserve the logs, identify the Lagoon user and source address in the surrounding entries, and review what that user could reach.
• No match is not proof of safety. Logs may have rotated, may not have been collected, or an attacker may have used a path that does not produce that message. The advisory says "may be detected", not "will always appear".

Fix and workarounds

The fix: upgrade to 2.33.2 or later

Lagoon's release policy says to upgrade to the latest release of each minor version before moving to the next minor. For a core on 2.32.x, that means moving to the latest 2.32 release, then to 2.33.2, and then to later releases such as 2.34.0 if you want them. For a core on 2.33.0 or 2.33.1, 2.33.2 is a direct step. Read the upgrade notes and deprecation notices for each version you cross.

Lagoon's update documentation gives the sequence. In summary:

# 1. Refresh chart repositories
helm repo update

# 2. See which lagoon-core chart versions are available
helm search repo lagoon/lagoon-core --versions | head -n 10

# 3. Preview changes with the helm-diff plugin, pinned to the fixed chart
helm diff upgrade --install --namespace lagoon-core \
  -f values.yaml lagoon-core lagoon/lagoon-core --version 1.62.2

# 4. Back up the API and Keycloak databases first (see the Lagoon update docs
#    for the exact mysqldump commands for lagoon-core-api-db-0 and lagoon-core-keycloak-db-0)

# 5. Scale the API to one pod to help the database migrations, then upgrade
helm upgrade --install --namespace lagoon-core \
  -f values.yaml lagoon-core lagoon/lagoon-core --version 1.62.2

# 6. Scale the API back up, then re-check the running ssh image tag

Use the exact backup commands from the Lagoon update page rather than improvising.

After the upgrade, repeat the checks from the previous section. The running uselagoon/ssh image should show v2.33.2 or later. If your values pin ssh.image.tag, remove the pin or move it forward, or the chart upgrade will leave the old image in place.

If you deploy Lagoon core through GitOps, make the change in the repository that holds the chart version and values, so the fix is reviewed, recorded and not reverted by the next sync.

The workaround: disable ssh, move users to ssh-portal

If you cannot upgrade quickly, the advisory's workaround is to disable the ssh service in Lagoon core. In chart terms that is a values change:

# values.yaml for lagoon-core
ssh:
  enabled: false

Disabling the broker removes the vulnerable component, but it also removes the SSH path your users depend on. Plan the replacement before you flip the switch:

• Shell access: enable ssh-portal in each Lagoon remote chart (sshPortal.enabled: true) and ssh-portal-api in core (sshPortalAPI.enabled: true). The advisory says these components are not affected. Each remote cluster then gets its own SSH endpoint, so users connect to the portal for the cluster their environment lives in.
• API tokens: the ssh-portal README notes that it does not generate tokens. If your users or scripts obtain Lagoon API tokens over SSH, enable ssh-token in core (sshToken.enabled: true). The README describes token and grant commands on that endpoint and recommends the Lagoon CLI for getting a token.
• Client changes: Lagoon's SSH docs recommend the Lagoon CLI's lagoon ssh command, which "automatically queries the Lagoon API to determine the optimal SSH endpoint to connect to". Users on the CLI should pick up the new endpoints; users with hand written SSH config, rsync wrappers or scripts that hard code the old host and port will need updates.
• NATS and TLS: ssh-portal relies on a NATS cluster across core and remotes with mutual TLS. Budget time if you have not set it up.

Treat the workaround as temporary: the vulnerable component is still in your core version and one values change away from coming back.

After the fix: review access and look back

Patching closes the hole going forward. It does not tell you whether someone used it in the two months since the fix shipped, or longer. Once you are on 2.33.2 or later:

1. Review Lagoon user accounts. Remove people who no longer need access, especially contractors and agency staff from finished projects. Check that automation accounts have the narrowest roles that work.
2. Rotate what the ssh service could reach. If you found the log string, or cannot rule out misuse, rotate credentials the ssh service and other core services hold, review Kubernetes RBAC bindings in the clusters Lagoon manages, and check for unexpected service accounts, role bindings or workloads. Our guide to Kubernetes RBAC mistakes that lead to cluster admin lists the bindings worth checking first.
3. Check Kubernetes audit logs for exec and attach activity by the identity the ssh service uses, outside the patterns your users normally produce. If you do not have audit logging set up, our Kubernetes audit logging policy starter is a reasonable baseline to add now.
4. Keep the evidence: dated log searches and version checks show when you learned of the flaw, fixed it and what you checked.

Technical details

The specifics defenders need, in one place, all taken from the advisory, the NVD record, the release notes and the chart sources:

The lagoon-core chart requires Kubernetes 1.25.0 or later per its Chart.yaml. The 2.34.0 release also upgrades Keycloak and refactors webhooks and notifications, so if you jump straight to it, read its notes as well as the 2.33.2 ones.

What would have helped

This flaw was fixed upstream before most organizations would have seen a CVE number. The teams that were patched before 21 October were not luckier. They did a few ordinary things well.

Practices any team can use

Know what platform software you run, with versions. Platform components like Lagoon core, ingress controllers, identity providers and CI runners are software you depend on just as much as your application libraries. They belong in your inventory with an exact version, the cluster they run in, and an owner. "We run Lagoon" is not an inventory entry. "Lagoon core 2.33.1, one chart version below the fix, production core cluster, owned by the platform team" (an illustration, not a statement about any real install) is.

Watch upstream advisories, not just CVE feeds. GitHub repository advisories, project release notes and security mailing lists often lead CVE publication by days or weeks. In this case the lead was about eight weeks. For the handful of platform projects that sit in the middle of your infrastructure, subscribe to their release and advisory notifications directly.

Pin versions in Git and gate them. This is general practice, not a Safeguard feature, and the script is an illustration to adapt. If the Lagoon core chart version lives in a Git repository, a pipeline check can fail any change that keeps it below a minimum. A minimal version of that check, with no special tooling, looks like this:

#!/usr/bin/env sh
# Fail if the pinned lagoon-core chart version is below the first fixed release
min="1.62.2"
current="$(yq '.spec.chart.spec.version' clusters/prod/lagoon-core-helmrelease.yaml)"
lowest="$(printf '%s\n%s\n' "$min" "$current" | sort -V | head -n 1)"
if [ "$lowest" != "$min" ]; then
  echo "lagoon-core chart $current is below $min (CVE-2026-113788)"; exit 1
fi
echo "lagoon-core chart $current is at or above $min"

Adjust the path and key to however your repository stores the chart version.

Keep accounts current and logs long. The precondition is a user account, so quarterly access reviews and offboarding tied to contract end shrink the attacker pool. The only detection hint is a log string, so ship core service logs to a central store with months of retention. Where the project offers a narrower design, such as ssh-portal with one endpoint per cluster, prefer it.

Where Safeguard fits

Safeguard did not discover this vulnerability and did not ship a fix for it; the Lagoon maintainers did both. Safeguard's part is the inventory and policy work around it, which is where most teams lose time: SBOMs for the images you run and for the platform software you operate, one place to ask which projects carry a given component and version, continuous scanning that re-evaluates projects daily as new CVEs are published, and policy gates that fail a CI job when a policy fails. The next section shows each step. Where Safeguard does not help: it does not detect exploitation of the ssh service, it does not read your Lagoon logs, and it does not change Lagoon core for you. The fix for a platform you run but do not build is the vendor's release, applied by you.

How Safeguard helps, step by step

This section walks through a practical setup for a platform team running Lagoon core. It uses only features shown in Safeguard's documentation.

Step 1: write a platform SBOM for Lagoon core

Create a CycloneDX file in the repository that holds your Lagoon core deployment, and update it in the same pull request that changes the chart version. A minimal example:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "version": 1,
  "metadata": {
    "component": {
      "type": "platform",
      "name": "lagoon-core-production",
      "version": "2026-10-27"
    }
  },
  "components": [
    {
      "type": "application",
      "name": "lagoon",
      "version": "2.33.2",
      "purl": "pkg:github/uselagoon/lagoon@v2.33.2"
    },
    {
      "type": "container",
      "name": "uselagoon/ssh",
      "version": "v2.33.2",
      "purl": "pkg:docker/uselagoon/ssh@v2.33.2"
    },
    {
      "type": "application",
      "name": "lagoon-core-chart",
      "version": "1.62.2",
      "description": "lagoon/lagoon-core Helm chart"
    }
  ]
}

Then validate it and run it through a scan:

# Check the document against the CycloneDX specification
safeguard validate platform-sbom.json --strict

# Build results from the SBOM you already have
safeguard scan --sbom platform-sbom.json --format cyclonedx

Before the upgrade, this file would have said 2.33.1. Next time an advisory names a Lagoon version, a search across your SBOMs answers "where do we run it?" without messaging every cluster owner.

Step 2: scan the images you actually deploy

From a machine that can pull your images, scan each core image at the tag the cluster runs:

# The tag here should come from the kubectl check in the earlier section
safeguard scan --image uselagoon/ssh:v2.33.2

# Images mirrored into a private registry
safeguard scan --image registry.example.com/mirror/uselagoon/ssh:v2.33.2 \
  --registry-username "$REGISTRY_USER" --registry-password "$REGISTRY_PASSWORD"

safeguard scan exits 0 whenever the scan ran; gating happens through policy gates in the platform. To see results alongside your other projects, scan from the interactive terminal while signed in (/scan).

Step 3: gate the deploy

Set up a policy that blocks critical findings and link it to a gate for the Lagoon core project. In the CI job that applies your Lagoon core changes, add the command below. Safeguard's policies and gates page says this form works when policy outcomes are on for your workspace, and lagoon-core-release is a placeholder gate name:

safeguard ci scan --wait --fail-on-gate lagoon-core-release

Keep the plain version check from "What would have helped" too: it catches a pin below the fixed release even before a CVE record exists, while the gate catches whatever the vulnerability data flags.

Step 4: record the workaround and report

If you disabled ssh instead of upgrading, record it as a risk acceptance with a justification and an expiration date set to your committed upgrade date, so the exception comes back for review instead of becoming permanent. Then export the findings for the Lagoon core project with your cluster version checks: affected versions, where you ran them, when you fixed each one and what you checked in the logs.

Common mistakes

• Trusting the CVE prose over the version range. "Prior to 2.33.1" in the description has led some people to mark 2.33.1 as fixed. It is not. The fix is 2.33.2.
• Checking the chart version but not the running image. A pinned ssh.image.tag in values, or an image from a private mirror, can leave an old uselagoon/ssh running after a chart upgrade.
• Treating "needs an account" as "not urgent". On any platform where developers outside your core team hold Lagoon accounts, the precondition is already met.
• Reading a clean log as a clean bill of health. The advisory says exploitation "may" show too many arguments. Rotated logs, short retention and other code paths all produce false comfort.
• Waiting for NVD analysis or a KEV listing. NVD still shows "Awaiting Analysis" and the CVE is not in KEV. Neither is a reason to wait when the vendor has rated it critical and shipped a fix two months ago.

FAQ

Is Lagoon 2.33.1 vulnerable to CVE-2026-113788?

Yes. The CVE description says "prior to 2.33.1", but the structured affected range in the same record and the GitHub advisory both say every version below 2.33.2 is affected. The 2.33.1 release contains no security fix. Upgrade to 2.33.2 or later.

Which Helm chart version contains the fix?

lagoon/lagoon-core chart 1.62.2, released 25 August 2026, which sets appVersion v2.33.2. Later charts such as 1.63.0, which ships Lagoon 2.34.0, also include it.

Is CVE-2026-113788 being exploited?

No exploitation is reported in the sources we checked. CISA's SSVC assessment on 23 October 2026 recorded exploitation as "none", and the CVE is not in the CISA KEV catalog as of the 26 October 2026 release. Check the advisory and NVD record again before you rely on that.

What does "too many arguments" in the ssh logs mean?

The advisory names it as a possible sign of exploitation in the ssh service container logs. If you find it, start incident response and preserve the logs. If you do not find it, that is not proof nothing happened, because logs rotate and the advisory says it "may" appear.

Is ssh-portal affected?

No. The advisory says the ssh-portal service and components are not affected and can continue to be used. Moving users to ssh-portal is part of the documented workaround.

Does disabling the ssh service break the Lagoon CLI?

It removes the legacy SSH endpoint, so shell access and SSH based token retrieval stop working until you enable ssh-portal in your remote clusters, ssh-portal-api in core and, if you use SSH token retrieval, ssh-token in core. The Lagoon CLI's lagoon ssh queries the API for the right endpoint.

Did Safeguard find this vulnerability?

No. The Lagoon project published the advisory and the fix. Safeguard helps with the inventory and policy side: knowing which versions you run where, and gating deploys that would keep a vulnerable version in place.

Checklist for this week, and what to tell leadership

For the platform team:

1. Run the helm list and kubectl checks against every Lagoon core, production and non production.
2. Upgrade any core below 2.33.2 to 2.33.2 or later, following the minor by minor upgrade policy and backing up both databases first.
3. If an upgrade has to wait, disable ssh and stand up ssh-portal, ssh-portal-api and ssh-token as needed. Record the exception with an expiry date.
4. Search central logs back to at least 25 August for too many arguments from the ssh service.
5. Review Lagoon user accounts and remove anyone who no longer needs access.
6. Add Lagoon core, with exact versions, to your SBOM inventory and put a version gate in front of the chart.
7. Subscribe to Lagoon's release and advisory notifications.

For leadership: "A critical flaw in our delivery platform's SSH component let any account holder run code with elevated permissions. The vendor fixed it on 25 August; we have upgraded (or will by a stated date), searched our logs and reviewed accounts. No exploitation has been reported publicly."

For more on running that lookup quickly, see our guide to SBOM incident response: finding affected products fast.

In this case upstream has already done its part: the Lagoon maintainers shipped 2.33.2 on 25 August, so the fastest path is to apply that release, or disable the ssh service until you can. The wider lesson still holds, because most of the time between a fix existing and a fix running is spent inside your own pipelines, and the dependencies and images you build yourself carry the same gaps.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Griffin, Safeguard's security model, opens a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. You install the CLI, run safeguard to open the interactive terminal and ask it to fix a lodash CVE in a repository. It reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The demo shows a package.json change, not a Lagoon change. For a Lagoon core values file you would make the same kind of request, moving the chart pin to 1.62.2, and review the diff before you commit it.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code, then scans from the terminal. For a platform team, that is how you scan the Lagoon core images you pull from your own registry without sending source anywhere.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask an assistant to look up a CVE's affected and fixed versions, which is a quick way to look up a CVE record while you plan the upgrade. Whether a given CVE is in your workspace's data depends on your account, so always confirm against the NVD record and the advisory.

Click through it at your own pace, or open it full screen.

To try it on your own platform, download Safeguard or start with the CLI documentation.

Quick check

Sources

• NVD: CVE-2026-113788
• GitHub security advisory GHSA-f8mw-q232-qjfp: Remote code execution via Lagoon core ssh service
• Lagoon release v2.33.2 (25 August 2026)
• Lagoon release v2.33.1 (31 July 2026)
• Lagoon docs: release 2.33.2
• Lagoon docs: release 2.34.0
• Lagoon docs: release and deprecation policy
• Lagoon docs: updating Lagoon
• Lagoon docs: SSH
• Lagoon docs: home and how Lagoon works
• lagoon-charts release lagoon-core-1.62.2
• lagoon-core chart Chart.yaml at 1.62.2
• lagoon-core chart values.yaml
• lagoon-remote chart values.yaml
• lagoon-ssh-portal README: Lagoon SSH services
• CISA Known Exploited Vulnerabilities catalog
• CISA: Stakeholder Specific Vulnerability Categorization
• MITRE CWE-78: OS Command Injection
• FIRST: CVSS v4.0 specification
• Safeguard docs: Policies and Gates
• Safeguard docs: Explore SBOM
• Safeguard docs: Vulnerabilities
• Safeguard docs: CLI usage

Last reviewed: 27 October 2026. Check the linked advisory and NVD record for the latest status.