This article is based on reporting originally published by TechTarget in January 2017. Quotes are attributed to the original sources.
Overview
No software is immune to bugs, and Docker is no exception. In January 2017, Docker container management received a pair of incremental but meaningful improvements: a security patch for a privilege-escalation vulnerability in runC, and a set of usability and bug-fix updates shipped as part of Docker 1.13. Together, they highlighted two persistent challenges in container environments — security depth and operational maturity.
CVE-2016-9962: runC Privilege-Escalation Vulnerability
In mid-January 2017, Docker responded to a security vulnerability in runC, the low-level container runtime, identified as CVE-2016-9962. The flaw could theoretically allow privilege escalation from a container to its host, and, in a worst-case scenario, provide a foothold for an attacker to move laterally within a corporate network.
Docker rated the severity of the bug as minor and released a fix in Docker 1.12.6. Exploiting the vulnerability required an attacker to first compromise the code running inside a container and control how that code was placed there — a significant prerequisite that limited real-world exposure.
What Made Exploitation Difficult
According to Edward Haletky, CEO and principal analyst at TVP Strategy (Austin, Texas), exploiting CVE-2016-9962 required first compromising the container’s code supply chain:
“In order to exploit CVE-2016-9962 in an attack, one must first compromise the code and the means by which the code is placed within the container.”
— Edward Haletky, TVP Strategy
Haletky stressed that patching alone is insufficient: container images should be evaluated for security before they enter any environment, and code security testing should be a standard part of the container deployment pipeline.
“Just patching or using SELinux is not enough of an answer. We need control and security testing of every aspect of container deployment.”
— Edward Haletky, TVP Strategy
Defense in Depth in Practice
Alex Witherspoon, VP of Platform Engineering at FlightStats Inc. (Portland, OR), noted that his organization was not affected by the vulnerability because complementary security controls were already in place:
“For us, other security systems not based in Docker were available to help negate any ill effect here. We also use New Relic and APM as a way to detect bad behavior in the environment, so we can automatically block or deny a bad actor.”
— Alex Witherspoon, FlightStats Inc.
Witherspoon’s approach illustrates the principle of defense in depth: layering independent security controls — firewalls, runtime monitoring, anomaly detection — so that no single vulnerability creates a complete breach.
Docker 1.13: Incremental but Important Updates
Released in late January 2017, Docker 1.13 bundled several quality-of-life improvements alongside the security work in 1.12.6. The key changes fell into four areas:
1. Backward-Compatible CLI
Docker 1.13 introduced backward compatibility for the Docker command-line interface, meaning that scripts and tooling built against older CLI versions would continue to work. Chris Riley, Director of Solutions Architecture at cPrime (San Francisco), commented:
“We stick with newer versions, but this will probably be very helpful for admins who are not constantly updating Docker.”
— Chris Riley, cPrime
2. Simplified Commands and Disk Management
The CLI was restructured with cleaner, more logical command groupings. Disk usage had been a recurring complaint among Docker users — dangling images, stopped containers, and unused volumes consuming space with no easy cleanup path. New commands in 1.13 targeted this directly.
“I have had a lot of clients complain about disk usage when using Docker, and [some of the new] commands are meant to help this issue and will be helpful. This is a nice refactor as they expand their API, and [it] helps keep things organized and focused.”
— Chris Riley, cPrime
3. Improved Container Log Access
Docker 1.13 also simplified how container logs are accessed, making it easier to integrate Docker logging with external monitoring and observability platforms — an important step for production operations teams.
4. Docker for AWS and Azure: General Availability
Docker for Amazon Web Services and Docker for Microsoft Azure both graduated from beta to general availability with the 1.13 release. Riley viewed this as a strategic move:
“The fact that [Docker is] targeting the ops side and the two largest cloud providers is smart. We have been waiting for this to compete with Kubernetes on AWS and Amazon ECS.”
— Chris Riley, cPrime
5. DNS Bug Fix
One fix that did not appear prominently in Docker’s own release notes — but mattered to practitioners — was a resolution of an intermittent DNS lookup failure in containers. Witherspoon described the issue:
“Some containers would rarely, but very painfully, fail to resolve certain DNS lookups for no apparent reason. It seems better now — time and testing will tell.”
— Alex Witherspoon, FlightStats Inc.
Intermittent DNS failures are notoriously hard to reproduce and diagnose in distributed systems, making this fix particularly valuable for production workloads that depend on service discovery.
The Broader Context: A Rapidly Evolving Ecosystem
The pace of Docker releases in this period reflects how quickly the container ecosystem was maturing. FlightStats had adopted a policy of tracking and deploying updates to both containers and the Docker daemon itself — a strategy that required accepting frequent churn in exchange for staying current with security patches and feature improvements.
“Docker is still very young and changing rapidly.”
— Alex Witherspoon, FlightStats Inc.
That observation — made in early 2017 — was accurate for the time and serves as a useful reminder that operational practices around any fast-moving platform must account for continuous change. Automated update pipelines, image scanning, and layered security controls are not optional extras; they are baseline requirements for running containers safely at scale.
Key Takeaways
- Patch promptly: CVE-2016-9962 was rated minor, but waiting to apply Docker 1.12.6 unnecessarily extended exposure.
- Layer your defenses: Firewalls, SELinux/AppArmor, runtime monitoring (APM), and image scanning together reduce the blast radius of any single vulnerability.
- Scan images before deployment: Since exploiting runC-class bugs requires compromising the container’s code supply chain, shifting security left — scanning images in CI/CD — is a direct mitigation.
- Monitor disk usage: Docker’s new cleanup commands in 1.13 addressed a real operational pain point; incorporate regular pruning into your container lifecycle management.
- Track DNS behavior: Intermittent DNS failures in containers can be difficult to attribute; update to releases that include DNS fixes and monitor resolution latency as a standard metric.