| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| SAP NetWeaver Application Server Java allows an attacker to access an endpoint that can disclose information about deployed server components, including their XML definitions. This information should ideally be restricted to customer administrators, even though they may not need it. These XML files are not entirely SAP-internal as they are deployed with the server. In such a scenario, sensitive information could be exposed without compromising its integrity or availability. |
| SAP GUI for Windows & RFC service credentials are incorrectly stored in the memory of the program allowing an unauthenticated attacker to access information within systems, resulting in privilege escalation. On successful exploitation, this could result in disclosure of highly sensitive information. This has no impact on integrity, and availability. |
| The ABAP Build Framework in SAP ABAP Platform allows an authenticated attacker to gain unauthorized access to a specific transaction. By executing the add-on build functionality within the ABAP Build Framework, an attacker could call the transaction and view its details. This has a limited impact on the confidentiality of the application with no effect on the integrity and availability of the application. |
| SAP Commerce (Backoffice) uses the deprecated X-FRAME-OPTIONS header to protect against clickjacking. While this protection remains effective now, it may not be the case in the future as browsers might discontinue support for this header in favor of the frame-ancestors CSP directive. Hence, clickjacking could become possible then, and lead to exposure and modification of sensitive information. |
| SAP Commerce, by default, sets certain cookies with the SameSite attribute configured to None (SameSite=None). This includes authentication cookies utilized in SAP Commerce Backoffice. Applying this setting reduces defense in depth against CSRF and may lead to future compatibility issues. |
| The SAP Approuter Node.js package version v16.7.1 and before is vulnerable to Authentication bypass. When trading an authorization code an attacker can steal the session of the victim by injecting malicious payload causing High impact on confidentiality and integrity of the application |
| regclient is a Docker and OCI Registry Client in Go. A malicious registry could return a different digest for a pinned manifest without detection. This vulnerability is fixed in 0.7.1. |
| go-ethereum (geth) is a golang execution layer implementation of the Ethereum protocol. A vulnerable node can be forced to shutdown/crash using a specially crafted message. This vulnerability is fixed in 1.14.13. |
| kube-audit-rest is a simple logger of mutation/creation requests to the k8s api. If the "full-elastic-stack" example vector configuration was used for a real cluster, the previous values of kubernetes secrets would have been disclosed in the audit messages. This vulnerability is fixed in 1.0.16. |
| pwn.college is an education platform to learn about, and practice, core cybersecurity concepts in a hands-on fashion. Missing access control on rendering custom (unprivileged) dojo pages causes ability for users to create stored XSS. |
| pwn.college is an education platform to learn about, and practice, core cybersecurity concepts in a hands-on fashion. Incorrect symlink checks on user specified dojos allows for users (admin not required) to perform an LFI from the CTFd container. When a user clones or updates repositories, a check is performed to see if the repository had contained any symlinks. A malicious user could craft a repository with symlinks pointed to sensitive files and then retrieve them using the CTFd website. |
| The SecureDrop Client is a desktop application for journalists to communicate with sources and work with submissions on the SecureDrop Workstation. Prior to version 0.14.1, a malicious SecureDrop Server could obtain code execution on the SecureDrop Client virtual machine (`sd-app`). SecureDrop Server itself has multiple layers of built-in hardening, and is a dedicated physical machine exposed on the internet only via Tor hidden services for the Source and Journalist interfaces, and optionally via remote SSH access over another Tor hidden service. A newsroom's SecureDrop Workstation communicates only with its own dedicated SecureDrop Server.
The SecureDrop Client runs in a dedicated Qubes virtual machine, named `sd-app`, as part of the SecureDrop Workstation. The private OpenPGP key used to decrypt submissions and replies is stored in a separate virtual machine and never accessed directly. The vulnerability lies in the code responsible for downloading replies. The filename of the reply is obtained from the `Content-Disposition` HTTP header and used to write the encrypted reply on disk. Note that filenames are generated and sanitized server-side, and files are downloaded in an encrypted format, so a remote attacker who has not achieved server compromise, such as one posing as a source, could not craft the HTTP response necessary for this attack.
While the filename is later checked to guard against path traversal before being moved into the Client’s data storage directory, the file has already been written to a potentially arbitrary location. In this case, `safe_move()` would detect the path traversal and fail, leaving the original downloaded file in the attacker-chosen directory. Code execution can be gained by writing an autostart file in `/home/user/.config/autostart/`.
Version 0.14.1 fixes the issue. As of time of publication, there is no known evidence of exploitation in the wild. This attack requires a previously compromised SecureDrop Server. |
| The SecureDrop Client is a desktop application for journalists to communicate with sources and work with submissions on the SecureDrop Workstation. Prior to versions 0.14.1 and 1.0.1, an attacker who has already gained code execution in a virtual machine on the SecureDrop Workstation could gain code execution in the `sd-log` virtual machine by sending a specially crafted log entry. The vulnerability is not exploitable remotely and requires an attacker to already have code execution on one of the other virtual machines (VMs) of the system. Due to the Workstation's underlying usage of Qubes for strong isolation, the vulnerability would have allowed lateral movement between any log-enabled VM and the `sd-log` VM, but no further. The SecureDrop workstation collects logs centrally in an isolated virtual machine named `sd-log` for easy export for support and debugging purposes. The `sd-log` VM is completely isolated from the internet and ingests logs via a narrow Qubes RPC policy that allows for specific inter-VM communication via the Xen vchan protocol used by Qubes's qrexec mechanism. A path traversal bug was found in the logic used to choose where to write the log file for a specific VM: the VM name, used unsanitized in the destination path in `sd-log`, is supplied by the logging VM itself instead of being read from a trusted source, such as the Qubes environment variable `QREXEC_REMOTE_DOMAIN` that is used in the fixed implementation. An attacker could provide an arbitrary source VM name, possibly overwriting logs of other VMs, or writing a file named `syslog.log`, with attacker-controlled content, in arbitrary directories as a low-privileged user. A successful attack could potentially overwrite or add configuration to software that loads configuration files from a directory. This is exploitable to achieve code execution by setting the target directory to `/home/user/.config/autostart/` and letting it write `syslog.log`, because XFCE treats any file in that directory as a `.desktop` file regardless of its extension. Versions 0.14.1 and 1.0.1 contain a patch for this issue. |
| Insecure information storage vulnerability in NTFS Tools version 3.5.1. Exploitation of this vulnerability could allow an attacker to know the application password, stored in /Users/user/Library/Application Support/ntfs-tool/config.json. |
| Dumb Drop is a file upload application. Users with permission to upload to the service are able to exploit a path traversal vulnerability to overwrite arbitrary system files. As the container runs as root by default, there is no limit to what can be overwritten. With this, it's possible to inject malicious payloads into files ran on schedule or upon certain service actions. As the service is not required to run with authentication enabled, this may permit wholly unprivileged users root access. Otherwise, anybody with a PIN. |
| SPID.AspNetCore.Authentication is an AspNetCore Remote Authenticator for SPID. Authentication using Spid and CIE is based on the SAML2 standard which provides two entities: Identity Provider (IDP): the system that authenticates users and provides identity information (SAML affirmation) to the Service Provider, in essence, is responsible for the management of the credentials and identity of users; Service Provider (SP): the system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The validation logic of the signature is central as it ensures that you cannot create a SAML response with arbitrary assertions and then impersonate other users. There is no guarantee that the first signature refers to the root object, it follows that if an attacker injects an item signed as the first element, all other signatures will not be verified. The only requirement is to have an XML element legitimately signed by the IdP, a condition that is easily met using the IdP's public metadata. An attacker could create an arbitrary SAML response that would be accepted by SPs using vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user. This vulnerability has been addressed in version 3.4.0 and all users are advised to upgrade. There are no known workarounds for this vulnerability. |
| CIE.AspNetCore.Authentication is an AspNetCore Remote Authenticator for CIE 3.0. Authentication using Spid and CIE is based on the SAML2 standard which provides two entities: 1. Identity Provider (IDP): the system that authenticates users and provides identity information (SAML affirmation) to the Service Provider, in essence, is responsible for the management of the credentials and identity of users; 2. Service Provider (SP): the system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library cie-aspnetcore refers to the second entity, the SP, and implements the validation logic of SAML assertions within SAML responses. In affected versions there is no guarantee that the first signature refers to the root object, it follows that if an attacker injects an item signed as the first element, all other signatures will not be verified. The only requirement is to have an XML element legitimately signed by the IdP, a condition that is easily met using the IdP's public metadata. An attacker could create an arbitrary SAML response that would be accepted by SPs using vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user. This issue has been addressed in version 2.1.0 and all users are advised to upgrade. There are no known workarounds for this vulnerability. |
| rust-openssl is a set of OpenSSL bindings for the Rust programming language. In affected versions `ssl::select_next_proto` can return a slice pointing into the `server` argument's buffer but with a lifetime bound to the `client` argument. In situations where the `sever` buffer's lifetime is shorter than the `client` buffer's, this can cause a use after free. This could cause the server to crash or to return arbitrary memory contents to the client. The crate`openssl` version 0.10.70 fixes the signature of `ssl::select_next_proto` to properly constrain the output buffer's lifetime to that of both input buffers. Users are advised to upgrade. In standard usage of `ssl::select_next_proto` in the callback passed to `SslContextBuilder::set_alpn_select_callback`, code is only affected if the `server` buffer is constructed *within* the callback. |
| Concorde, formerly know as Nexkey, is a fork of the federated microblogging platform Misskey. Due to a lack of CSRF countermeasures and improper settings of cookies for MediaProxy authentication, there is a vulnerability that allows MediaProxy authentication to be bypassed. In versions prior to 12.25Q1.1, the authentication cookie does not have the SameSite attribute. This allows an attacker to bypass MediaProxy authentication and load any image without restrictions under certain circumstances. In versions prior to 12.24Q2.3, this cookie was also used to authenticate the job queue management page (bull-board), so bull-board authentication is also bypassed. This may enable attacks that have a significant impact on availability and integrity.
The affected versions are too old to be covered by this advisory, but the maintainers of Concorde strongly recommend not using older versions. Version 12.25Q1.1 contains a patch. There is no effective workaround other than updating. |
| Improper neutralization for some Edge Orchestrator software before version 24.11.1 for Intel(R) Tiber(TM) Edge Platform may allow an unauthenticated user to potentially enable information disclosure via adjacent access. |
