In July 2022, the Harbor container registry project disclosed CVE-2022-31663, a vulnerability in its cross-site request forgery (CSRF) protections that allowed an attacker to predict or forge valid CSRF tokens and trick an authenticated victim into executing state-changing actions without consent. Because Harbor is one of the most widely deployed open-source container registries in cloud-native environments, a CSRF bypass that can be chained into session hijack and account takeover is a serious concern for any organization storing, signing, or scanning images through it.
CVE-2022-31663 matters not because it is a novel attack class — CSRF is a decades-old vulnerability category — but because it undermined a control that registry administrators reasonably assumed was working. When CSRF protection can be bypassed on a system that governs image provenance, robot account credentials, and project-level RBAC, the blast radius extends well beyond a single browser session into the software supply chain itself.
What Is Harbor, and What CVE-2022-31663 Actually Affected
Harbor is a CNCF graduated project used as a trusted registry for storing, signing, and scanning container images, Helm charts, and other OCI artifacts. Its core service is built on the Beego web framework, which ships built-in XSRF/CSRF token handling used to protect Harbor's web console and API endpoints from forged cross-origin requests.
The flaw behind CVE-2022-31663 lived in this anti-CSRF token generation and validation logic. Under normal operation, a CSRF token should be unpredictable and cryptographically bound to the user's session, so that a malicious site cannot construct a request on the victim's behalf that Harbor will accept as legitimate. In the affected Harbor releases, the token generation was weak enough that an attacker could derive or predict a valid token for a target session. With a forged token in hand, an attacker could lure an authenticated Harbor user — potentially an administrator — into visiting a malicious page that silently submitted authenticated requests to Harbor's API, effectively hijacking the privileges of that session to perform actions such as modifying account details, project settings, or robot account permissions.
This is what elevates CVE-2022-31663 from a textbook CSRF finding to a session hijack primitive: the attacker doesn't need to steal a session cookie directly, only to ride on top of an active one by defeating the control meant to stop exactly that.
Affected Versions and Components
The vulnerability was disclosed as part of a batch of Harbor security fixes affecting multiple actively maintained release branches. Harbor's maintainers addressed CVE-2022-31663 alongside several related advisories (covering privilege escalation and session-handling issues) in patch releases across the 2.1.x, 2.2.x, 2.3.x, 2.4.x, and 2.5.x branches, consistent with how the Harbor project typically backports security fixes to every branch it supports at time of disclosure. Organizations running any Harbor deployment from that era — whether self-hosted on Kubernetes, deployed via Helm chart, or bundled into a larger DevOps platform — should treat any instance not updated since mid-2022 as potentially exposed.
The affected component is specifically Harbor Core's web-facing CSRF middleware, meaning the exposure applies to any user session interacting with the Harbor UI or API over a browser — not to registry pull/push operations authenticated via Docker/OCI clients using separate token flows.
CVSS, EPSS, and KEV Context for CVE-2022-31663
The National Vulnerability Database rated CVE-2022-31663 as High severity, reflecting a CVSS v3.1 base score in the 8.x range, driven by a vector requiring user interaction (a victim visiting an attacker-controlled page) but capable of impacting confidentiality and integrity through a changed scope — the hallmark of a CSRF-to-session-hijack chain. Attack complexity was rated higher than a typical CSRF issue precisely because it depended on defeating the token prediction, not just the absence of a token check.
CVE-2022-31663 is not currently listed on CISA's Known Exploited Vulnerabilities (KEV) catalog, and public EPSS scoring has stayed low, consistent with no widely observed mass exploitation in the wild. That said, low observed exploitation is not the same as low risk: registry compromises are high-value, low-noise targets, and vulnerabilities like this one are exactly the kind that get quietly weaponized in targeted supply chain intrusions rather than broad opportunistic scanning.
Disclosure Timeline
Harbor's maintainers coordinated disclosure of CVE-2022-31663 alongside a set of related security advisories in July 2022, publishing patched releases across supported branches at the same time the advisory went public — the standard responsible-disclosure pattern for CNCF projects, where fixes ship before or concurrent with public writeups to minimize the window of exposure. Downstream distributions that bundle Harbor (managed Kubernetes platforms, internal platform-engineering stacks, CI/CD toolchains) generally picked up the fix in subsequent release trains over the following weeks, which is typically the longer tail of real-world remediation for this class of finding — the upstream patch existing is not the same as every fork and vendored copy actually consuming it.
Remediation Steps
Organizations running Harbor should treat this as a standard "patch and verify" vulnerability rather than one requiring exotic mitigations:
- Upgrade Harbor to a patched release on your branch (2.1.6, 2.2.4, 2.3.4, 2.4.3, 2.5.3, or later, or any subsequent major version, all of which include the fix). Do not rely on point-in-time patching of a single branch if you have multiple Harbor instances running different minor versions across environments.
- Invalidate active sessions post-upgrade. Since the underlying issue is session-bound token predictability, rotating session secrets and forcing re-authentication closes any window where a pre-patch token could still be leveraged.
- Audit admin and robot account activity around the disclosure window for unexplained configuration changes, new robot accounts, or permission escalations that could indicate the flaw was exploited before patching.
- Review reverse proxy and ingress configuration in front of Harbor to ensure
SameSitecookie attributes and referrer/origin checks are enforced as defense-in-depth, since CSRF protections should never be the sole control against forged cross-origin requests. - Inventory every Harbor instance in your environment, including ones spun up by individual teams or embedded in platform templates — CSRF-class registry vulnerabilities are easy to miss in shadow deployments that never make it into a central patch cycle.
- Track downstream bundlers. If Harbor arrived via a Kubernetes operator, a vendor appliance, or an internal platform image, confirm that bundler has actually ingested the upstream fix rather than assuming it inherited the patch automatically.
How Safeguard Helps
CVE-2022-31663 is a useful case study in why software supply chain security teams can't treat container registries as trusted infrastructure by default — the registry is itself software, with its own CVEs, its own patch cadence, and its own blast radius when a control like CSRF protection quietly fails.
Safeguard is built to catch exactly this pattern before it becomes an incident. Our platform continuously inventories the software running across your environment — including infrastructure components like Harbor, not just application dependencies — and maps known vulnerabilities like CVE-2022-31663 against the actual versions deployed, so a stale registry instance doesn't sit unpatched simply because no one owns tracking it. Safeguard correlates CVSS severity, EPSS exploitation likelihood, and CISA KEV status to help teams prioritize which container registry and supply chain findings need immediate remediation versus scheduled patching, rather than treating every CVE as equally urgent.
Beyond detection, Safeguard's policy engine can flag and block deployments running affected Harbor versions from being promoted into production pipelines, and its provenance tracking helps verify that images signed or scanned by a given registry instance weren't touched during a window when that registry's session and CSRF controls were known to be compromised. For organizations running Harbor as a core piece of their container supply chain, that combination of continuous inventory, risk-prioritized alerting, and pipeline-level enforcement turns a vulnerability like CVE-2022-31663 from a scramble into a routine, auditable patch cycle.
If you're unsure whether your Harbor deployments — or any other registry infrastructure — are exposed to known CVEs like this one, Safeguard can run a supply chain exposure assessment across your environment to find out.