Property
Language
Severity
CWE	CWE-250: Execution with Unnecessary Privileges
Confidence Level	Medium
Impact Level	High
Likelihood Level	Low

Description

Mounting the host’s Docker socket (/var/run/docker.sock) into a container gives that container full control over the Docker daemon. This effectively grants root-level access to your host system from within the container.

Impact

If exploited, an attacker with access to the container could execute commands as root on the host, deploy or remove containers, access sensitive host files, or take over the entire host machine. This exposes your infrastructure to severe compromise and data breaches.

Property
Language
Severity
CWE	CWE-250: Execution with Unnecessary Privileges
Confidence Level	Medium
Impact Level	Medium
Likelihood Level	Medium

Description

The container or pod is configured to run in privileged mode, giving it broad access to the host system. This setting should be avoided as it grants the container unnecessary system-level privileges.

Impact

If exploited, an attacker could break out of the container to access or control the host machine, potentially leading to full system compromise, data breaches, or disruption of other workloads running on the same host.

Property
Language
Severity
CWE	CWE-250: Execution with Unnecessary Privileges
OWASP	A05:2021 - Security Misconfiguration
Confidence Level	Low
Impact Level	Low
Likelihood Level	Low

Description

The container is configured to run as the root user because the ‘runAsNonRoot: true’ setting is missing in the Kubernetes securityContext. Running containers as root increases the risk of privilege escalation if the application is compromised.

Impact

If exploited, an attacker who gains access to the container could obtain root privileges, allowing them to modify system files, escalate privileges, or access sensitive data. This could lead to a full compromise of the container and potentially the host or other services in the cluster.

Property
Language
Severity
CWE	CWE-250: Execution with Unnecessary Privileges
OWASP	A05:2021 - Security Misconfiguration
Confidence Level	Low
Impact Level	Low
Likelihood Level	Low

Description

The container is allowed to run as the root user because the ‘runAsNonRoot: true’ setting is missing from its security context. This increases the risk of privilege escalation within your Kubernetes pods.

Impact

If exploited, an attacker could gain root-level access inside the container, potentially allowing them to access sensitive data, manipulate the environment, or break out of the container to compromise the host or other containers, putting your application and infrastructure at risk.

Property
Language
Severity
CWE	CWE-250: Execution with Unnecessary Privileges
OWASP	A06:2017 - Security Misconfiguration
Confidence Level	Low
Impact Level	High
Likelihood Level	Low

Description

Mounting the host’s Docker socket inside a container gives that container full control over the Docker daemon. This setup allows the container to manage, create, or delete other containers and access sensitive host resources.

Impact

If a container with access to the Docker socket is compromised, an attacker can gain root-level control over the host system. This could lead to unauthorized code execution, data theft, or complete takeover of the server running Docker.

Property
Language
Severity
CWE	CWE-250: Execution with Unnecessary Privileges
OWASP	A06:2017 - Security Misconfiguration
Confidence Level	High
Impact Level	High
Likelihood Level	High

Description

The service is configured to run in privileged mode, which gives the container full root-level access to the host system. This setting bypasses many security restrictions and should be avoided unless absolutely necessary.

Impact

If exploited, an attacker could escape the container and gain control over the host machine, potentially accessing sensitive data, modifying system files, or taking down other services. This greatly increases the risk of a full system compromise.

Property
Language
Severity
CWE	CWE-250: Execution with Unnecessary Privileges
OWASP	A06:2017 - Security Misconfiguration
Confidence Level	Medium
Impact Level	High
Likelihood Level	High

Description

The IAM policy allows anyone (using a wildcard ‘*’) to assume a specific AWS role via sts:AssumeRole. This means the role can be assumed by any AWS principal, not just trusted users or accounts.

Impact

An attacker who knows your AWS account ID and role name could gain access to sensitive resources or perform actions as that role, potentially leading to data breaches, privilege escalation, or unauthorized changes in your AWS environment.

Property
Language
Severity
CWE	CWE-250: Execution with Unnecessary Privileges
Confidence Level	Low
Impact Level	Low
Likelihood Level	Low

Description

The policy grants permissions to sensitive IAM or Glue actions that can enable privilege escalation, such as attaching policies or modifying roles, without explicit deny statements. This allows users or roles to gain more access than intended.

Impact

If exploited, an attacker could escalate their privileges to gain administrative access over your AWS account, potentially leading to full control over resources, data breaches, or disruption of services. Unauthorized changes to IAM or Glue settings can compromise the entire cloud environment.

Property
Language
Severity
CWE	CWE-250: Execution with Unnecessary Privileges
OWASP	A06:2017 - Security Misconfiguration
Confidence Level	Medium
Impact Level	Medium
Likelihood Level	Medium

Description

Detected wildcard access granted to sts:AssumeRole. This means anyone with your AWS account ID and the name of the role can assume the role. Instead, limit to a specific identity in your account, like this: arn:aws:iam::<account_id>:root.

Property
Language
Severity
CWE	CWE-250: Execution with Unnecessary Privileges
OWASP	A05:2021 - Security Misconfiguration
Confidence Level	High
Impact Level	Low
Likelihood Level	Low

Description

Using ‘sudo’ in a Dockerfile grants unnecessary root privileges to processes, increasing the risk if the container is compromised. Best practice is to avoid ‘sudo’ and run processes as a non-root user inside containers.

Impact

If an attacker exploits a vulnerability in your container, having root privileges (granted by ‘sudo’) could let them modify system files, escalate attacks, or break out of the container, potentially affecting the host system or other containers.