Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/apache/trafficcontrol >= 6.0.0, < 6.0.1; >= 5.1.0, < 5.1.4
Fixed in
6.0.15.1.4· Vendor fix available
Issue
An unauthenticated Apache Traffic Control Traffic Ops user can send a request with a specially-crafted username to the POST /login endpoint of any API version to inject unsanitized content into the LDAP filter.
Recommended action: Upgrade to 6.0.1 or 5.1.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
1.8.11.1.4-0.20170531185407-738c10fa1b580.0.0-20170531185407-738c10fa1b582.0.02.1.0-RC1· Vendor fix available
Issue
The Traffic Router component of the incubating Apache Traffic Control project is vulnerable to a Slowloris style Denial of Service attack. TCP connections made on the configured DNS port will remain in the ESTABLISHED state until the client explicitly closes the connection or Traffic Router is restarted. If connections remain in the ESTABLISHED state indefinitely and accumulate in number to match the size of the thread pool dedicated to processing DNS requests, the thread pool becomes exhausted. Once the thread pool is exhausted, Traffic Router is unable to service any DNS request, regardless of transport protocol.
Recommended action: Upgrade to 2.1.0-RC1 (pre-release), 2.0.0, 1.8.1 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/apache/trafficcontrol >= 6.0.0, < 6.1.0; < 5.1.6
Fixed in
5.1.66.1.0· Vendor fix available
Issue
In Apache Traffic Control Traffic Ops prior to 6.1.0 or 5.1.6, an unprivileged user who can reach Traffic Ops over HTTPS can send a specially-crafted POST request to /user/login/oauth to scan a port of a server that Traffic Ops can reach.
Recommended action: Upgrade to 6.1.0 or 5.1.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An authenticated Apache Traffic Control Traffic Ops user with Portal-level privileges can send a request with a specially-crafted email subject to the /deliveryservices/request Traffic Ops endpoint to send an email, from the Traffic Ops server, with an arbitrary body to an arbitrary email address. Apache Traffic Control 5.1.x users should upgrade to 5.1.3 or 6.0.0. 4.1.x users should upgrade to 5.1.3.
Recommended action: Upgrade to 5.1.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When ORT (now via atstccfg) generates ipallow.config files in Apache Traffic Control 3.0.0 to 3.1.0 and 4.0.0 to 4.1.0, those files include permissions that allow bad actors to push arbitrary content into and remove arbitrary content from CDN cache servers. Additionally, these permissions are potentially extended to IP addresses outside the desired range, resulting in them being granted to clients possibly outside the CDN arcitechture.
Recommended action: Upgrade to 5.0.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/apache/trafficcontrol >= 3.0.0, <= 3.0.1
Fixed in
3.0.2-RC1· Vendor fix available
Issue
Improper authentication is possible in Apache Traffic Control versions 3.0.0 and 3.0.1 if LDAP is enabled for login in the Traffic Ops API component. Given a username for a user that can be authenticated via LDAP, it is possible to improperly authenticate as that user without that user's correct password.
Recommended action: Upgrade to 3.0.2-RC1 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.