35 lines
5.1 KiB
Plaintext
35 lines
5.1 KiB
Plaintext
cve: ./data/2021/21xxx/CVE-2021-21979.json
|
||
In Bitnami Containers, all Laravel container versions prior to: 6.20.0-debian-10-r107 for Laravel 6, 7.30.1-debian-10-r108 for Laravel 7 and 8.5.11-debian-10-r0 for Laravel 8, the file /tmp/app/.env is generated at the time that the docker image bitnami/laravel was built, and the value of APP_KEY is fixed under certain conditions. This value is crucial for the security of the application and must be randomly generated per Laravel installation. If your application's encryption key is in the hands of a malicious party, that party could craft cookie values using the encryption key and exploit vulnerabilities inherent to PHP object serialization / unserialization, such as calling arbitrary class methods within your application.
|
||
|
||
analysis: ```json
|
||
{"Container":"bitnami/laravel","CVE_Reason":"APP_KEY in the /tmp/app/.env file","CVE_Consequence":"If a malicious party obtains the encryption key, they could exploit PHP object serialization/unserialization vulnerabilities to call arbitrary class methods within the application. This is considered a high severity issue."}
|
||
```
|
||
|
||
cve: ./data/2022/29xxx/CVE-2022-29186.json
|
||
Rundeck is an open source automation service with a web console, command line tools and a WebAPI. Rundeck community and rundeck-enterprise docker images contained a pre-generated SSH keypair. If the id_rsa.pub public key of the keypair was copied to authorized_keys files on remote host, those hosts would allow access to anyone with the exposed private credentials. This misconfiguration only impacts Rundeck Docker instances of PagerDuty® Process Automation On Prem (formerly Rundeck) version 4.0 and earlier, not Debian, RPM or .WAR. Additionally, the id_rsa.pub file would have to be copied from the Docker image filesystem contents without overwriting it and used to configure SSH access on a host. A patch on Rundeck's `main` branch has removed the pre-generated SSH key pair, but it does not remove exposed keys that have been configured. To patch, users must run a script on hosts in their environment to search for exposed keys and rotate them. Two workarounds are available: Do not use any pre-existing public key file from the rundeck docker images to allow SSH access by adding it to authorized_keys files and, if you have copied the public key file included in the docker image, remove it from any authorized_keys files.
|
||
|
||
analysis: {"Container":"Rundeck community and rundeck-enterprise docker images","CVE_Reason":"pre-generated SSH keypair","CVE_Consequence":"If the pre-generated SSH private key is exposed, it allows unauthorized access to remote hosts that have the corresponding public key in their authorized_keys files. This could lead to unauthorized system access and potential data compromise. The severity is high as it affects the security of SSH communications and access control."}
|
||
|
||
cve: ./data/2023/22xxx/CVE-2023-22746.json
|
||
CKAN is an open-source DMS (data management system) for powering data hubs and data portals. When creating a new container based on one of the Docker images listed below, the same secret key was being used by default. If the users didn't set a custom value via environment variables in the `.env` file, that key was shared across different CKAN instances, making it easy to forge authentication requests. Users overriding the default secret key in their own `.env` file are not affected by this issue. Note that the legacy images (ckan/ckan) located in the main CKAN repo are not affected by this issue. The affected images are ckan/ckan-docker, (ckan/ckan-base images), okfn/docker-ckan (openknowledge/ckan-base and openknowledge/ckan-dev images)
|
||
keitaroinc/docker-ckan (keitaro/ckan images).
|
||
|
||
analysis: ```json
|
||
{"Container":"ckan/ckan-docker, ckan/ckan-base, okfn/docker-ckan, openknowledge/ckan-base, openknowledge/ckan-dev, keitaroinc/docker-ckan, keitaro/ckan","CVE_Reason":"secret key","CVE_Consequence":"Authentication requests can be forged, leading to unauthorized access (High severity)"}
|
||
```
|
||
|
||
cve: ./data/2025/32xxx/CVE-2025-32754.json
|
||
In jenkins/ssh-agent Docker images 6.11.1 and earlier, SSH host keys are generated on image creation for images based on Debian, causing all containers based on images of the same version use the same SSH host keys, allowing attackers able to insert themselves into the network path between the SSH client (typically the Jenkins controller) and SSH build agent to impersonate the latter.
|
||
|
||
analysis: ```json
|
||
{"Container":"jenkins/ssh-agent","CVE_Reason":"SSH host keys","CVE_Consequence":"允许攻击者冒充SSH构建代理，严重程度高"}
|
||
```
|
||
|
||
cve: ./data/2025/32xxx/CVE-2025-32755.json
|
||
In jenkins/ssh-slave Docker images based on Debian, SSH host keys are generated on image creation for images based on Debian, causing all containers based on images of the same version use the same SSH host keys, allowing attackers able to insert themselves into the network path between the SSH client (typically the Jenkins controller) and SSH build agent to impersonate the latter.
|
||
|
||
analysis: ```json
|
||
{"Container":"jenkins/ssh-slave","CVE_Reason":"SSH host keys","CVE_Consequence":"Impersonation of SSH build agents by attackers, leading to potential data interception or tampering. High severity."}
|
||
```
|
||
|