Cloudanix VulnDB

CVE-2017-11468

High · 7.5

CVSS

7.5

EPSS

3.2%

Published

Jul 20, 2017

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

Attackers can flood a container registry with oversized data and make it stop working, preventing teams from storing or retrieving container images.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Denial Of Service
Component
Application
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The registry fails to enforce size limits on user-supplied content at the manifest endpoint, allowing unbounded memory allocation that exhausts available RAM and produces a denial of service.

Why it matters to the business

Registry services become unavailable, halting image pushes, pulls, and deployments across dependent build and runtime systems until the process is restarted or memory pressure subsides.

How an attack unfolds

An unauthenticated remote attacker repeatedly posts oversized manifest payloads to the registry's manifest endpoint; each request triggers allocation of memory proportional to the payload size until the service is starved or crashes.

How to fix it

Upgrade distribution/distribution to commit 48294d928ced5dd9b378f7fd7c6f5da3ff3f2c89 or later; upgrade tekton-chains (Chainguard or Wolfi) to 0.20.1-r4 or later. Enforce network-level rate limiting or request-size caps in front-end proxies until patches are applied.

How to confirm the fix worked

Confirm the running binary or image reports a fixed version or commit; replay a manifest larger than the historical default limit and verify the request is rejected with an appropriate error rather than consuming memory.

Typical attack path

  1. Identify an exposed Docker Registry instance
  2. Craft HTTP POST requests containing arbitrarily large manifest bodies
  3. Send requests to the /v2/<name>/manifests/<reference> endpoint without authentication
  4. Repeat until memory consumption triggers service degradation or restart

How to detect it

Inspect HTTP access logs for POST requests to manifest endpoints that carry unusually large Content-Length values; correlate with sudden spikes in resident memory or out-of-memory events in registry process telemetry.

What your security team should do

  • Apply the listed fixed versions immediately on all registry deployments
  • Place the registry behind a reverse proxy that enforces request body size limits
  • Monitor memory usage and restart policies for registry containers
  • Review and restrict network exposure of the manifest endpoint

The record

Docker Registry before 2.6.2 in Docker Distribution does not properly restrict the amount of content accepted from a user, which allows remote attackers to cause a denial of service (memory consumption) via the manifest endpoint.

Affected packages

Ecosystem Package Introduced Fixed
Go github.com/docker/distribution 0 2.7.0-rc.0+incompatible
Go github.com/docker/distribution 0 2.7.0-rc.0
Debian:11 docker-registry 0 2.6.2~ds1-1
Debian:12 docker-registry 0 2.6.2~ds1-1
Debian:13 docker-registry 0 2.6.2~ds1-1
Debian:14 docker-registry 0 2.6.2~ds1-1
Red Hat:rhel_extras_other:7 docker-distribution 0 0:2.6.2-1.git48294d9.el7
SUSE:Linux Enterprise Module for Containers 12 docker-distribution 0 2.6.2-13.6.1
SUSE:Package Hub 15 SP2 docker-distribution 0 2.7.1-bp152.4.3.1
Ubuntu:18.04:LTS docker-registry 0 2.6.2~ds1-1
Ubuntu:20.04:LTS docker-registry 0 2.7.1+ds2-7ubuntu0.3
Ubuntu:Pro:16.04:LTS docker-registry 0 2.3.0~ds1-1ubuntu0.1~esm1
Ubuntu:Pro:18.04:LTS docker-registry 0 2.6.2~ds1-1ubuntu0.1~esm1
Ubuntu:Pro:22.04:LTS docker-registry 0 2.8.0+ds1-4ubuntu0.1~esm2
openSUSE:Tumbleweed distribution-registry 0 2.8.1-1.1
openSUSE:Tumbleweed docker-distribution-registry 0 2.7.1-7.2

Related vulnerabilities