#docker

Icingaweb versions from 2.9.0 to 2.9.5 inclusive, and 2.8.0 to 2.8.5 inclusive suffer from an unauthenticated directory traversal vulnerability. The vulnerability is triggered through the icinga-php-thirdparty library, which allows unauthenticated users to retrieve arbitrary files from the targets filesystem via a GET request to /lib/icinga/icinga-php-thirdparty/ as the user running the Icingaweb server, which will typically be the www-data user. This can then be used to retrieve sensitive configuration information from the target such as the configuration of various services, which may reveal sensitive login or configuration information, the /etc/passwd file to get a list of valid usernames for password guessing attacks, or other sensitive files which may exist as part of additional functionality available on the target server. This Metasploit module was tested against Icingaweb 2.9.5 running on Docker.

This Metasploit module exploits a memory disclosure vulnerability in Elasticsearch 7.10.0 to 7.13.3 (inclusive). A user with the ability to submit arbitrary queries to Elasticsearch can generate an error message containing previously used portions of a data buffer. This buffer could contain sensitive information such as Elasticsearch documents or authentication details. This vulnerabilitys output is similar to heartbleed.

# Name Updating a DID with a nym transaction will be written to the ledger if neither ROLE or VERKEY are being changed, regardless of sender. # Description A malicious DID with no particular role can ask an update for another DID (but cannot modify its verkey or role). This is bad because: 1. Any DID can write a nym transaction to the ledger (i.e., any DID can spam the ledger with nym transactions). 1. Any DID can change any other DID's alias. 1. The update transaction modifies the ledger metadata associated with a DID. # Expected vs Observed We expect that if a DID (with no role) wants to update another DID (not its own or one it is the endorser), then the nodes should refuse the request. We can see that requirements in the [Indy default auth_rules](https://github.com/hyperledger/indy-node/blob/master/docs/source/auth_rules.md) in Section "Who is the owner" in the last point of "Endorser using". We observe that with a normal DID, we can update the field `from` for a random DID, ...

Attackers are increasingly using new phishing toolkits (open-source, commercial, and criminal) to execute adversary-in-the-middle (AitM) attacks. AitM enables attackers to not just harvest credentials but steal live sessions, allowing them to bypass traditional phishing prevention controls such as MFA, EDR, and email content filtering. In this article, we’re going to look at what AitM phishing

Build Your Own Botnet (BYOB) version 2.0.0 exploit that works by spoofing an agent callback to overwrite the sqlite database and bypass authentication and exploiting an authenticated command injection in the payload builder page.

A team of researchers from the CISPA Helmholtz Center for Information Security in Germany has disclosed an architectural bug impacting Chinese chip company T-Head's XuanTie C910 and C920 RISC-V CPUs that could allow attackers to gain unrestricted access to susceptible devices. The vulnerability has been codenamed GhostWrite. It has been described as a direct CPU bug embedded in the hardware, as

Microweber version 1.0 suffers from a cross site scripting vulnerability in the search functionality. Original discovery of cross site scripting in this version is attributed to tmrswrr in June of 2024.

Ivanti ADC version 9.9 suffers from an authentication bypass vulnerability.

### Summary Probably jwt bypass + sql injection or what i'm doing wrong? ### PoC (how to reproduce) 1. Create following files: docker-compose.yml: ``` services: postgres: image: postgres container_name: postgres_container_mre environment: POSTGRES_USER: test_user_pg POSTGRES_PASSWORD: test_pass_pg POSTGRES_DB: test_db prest: image: prest/prest build: . volumes: - ./queries:/queries - ./migrations:/migrations ports: - "3000:3000" ``` Dockerfile: ``` from prest/prest:latest COPY ./prest.toml prest.toml ``` prest.toml: ``` debug=false migrations = "./migrations" [http] port = 3000 [jwt] default = true key = "secret" algo = "HS256" [auth] enabled = true type = "body" encrypt = "MD5" table = "prest_users" username = "username" password = "password" [pg] URL = "postgresql://test_user_pg:test_pass_pg@postgres:5432/test_db/?sslmode=disable" [ssl] mode = "disable" sslcert = "./PATH" sslkey = "./PATH" sslrootcert = "....

A security vulnerability has been detected in certain versions of Docker Engine, which could allow an attacker to bypass [authorization plugins (AuthZ)](https://docs.docker.com/engine/extend/plugins_authorization/) under specific circumstances. The base likelihood of this being exploited is low. This advisory outlines the issue, identifies the affected versions, and provides remediation steps for impacted users. ### Impact Using a specially-crafted API request, an Engine API client could make the daemon forward the request or response to an [authorization plugin](https://docs.docker.com/engine/extend/plugins_authorization/) without the body. In certain circumstances, the authorization plugin may allow a request which it would have otherwise denied if the body had been forwarded to it. A security issue was discovered In 2018, where an attacker could bypass AuthZ plugins using a specially crafted API request. This could lead to unauthorized actions, including privilege escalation. A...