| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A further incomplete fix for a previous advisory CVE-2026-44417 (Untrusted JMS configuration can lead to RCE) for Apache CXF has been identified, which can allow code execution capabilities, if untrusted users are allowed to configure JMS for Apache CXF. Users are recommended to upgrade to versions 4.2.2 or 4.1.7 or 3.6.12, which fixes this issue. |
| Deserialization of Untrusted Data vulnerability in the Go implementation of Apache Fory allows an attacker to cause a denial of service by supplying crafted data containing malformed type metadata, which triggers an uncaught panic.
This issue affects Apache Fory: from 0.16.0 before 1.5.0. Users of other language implementations are not affected.
Users are recommended to upgrade to version 1.5.0, which fixes the issue. |
| In Remoting 3384.v60d89463d9e0 and earlier, except 3355.3357.v931d3c992987, included in Jenkins 2.575 and earlier, LTS 2.568.1 and earlier, the JEP-200 class filter is not applied to classes resolved via a fallback path in the Remoting deserialization implementation, allowing agent processes, code running on agents, and attackers with Agent/Connect permission to bypass the JEP-200 deserialization filter for classes on the Jenkins core classpath. |
| Apache CXF's JMS transport deserializes the body of any inbound JMS ObjectMessage using native Java deserialization, with no type restrictions in place. Any attacker able to place a message on the service's JMS destination can submit a malicious serialized object, leading to denial of service or, if a suitable gadget class is on the classpath, remote code execution. The fix disables ObjectMessage deserialization by default, with a configuration switch to re-enable it if needed. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue. |
| Unauthenticated PHP Object Injection in WPBruiser {no- Captcha anti-Spam} <= 3.1.43 versions. |
| Unauthenticated PHP Object Injection in 69 Clothing <= 1.2.11.1 versions. |
| Unauthenticated PHP Object Injection in A.Williams <= 1.3.1 versions. |
| Unauthenticated PHP Object Injection in Ajax Search Lite <= 4.14.4 versions. |
| Unauthenticated PHP Object Injection in Accalia <= 1.5.3 versions. |
| Unauthenticated PHP Object Injection in AI ANN <= 1.29.0 versions. |
| Unauthenticated PHP Object Injection in Agricola <= 1.21.0 versions. |
| Deserialization of untrusted data vulnerability in Johnson Control victor on Windows, Johnson Controls CCure 9000, and Johnson Controls Victor Application Server allows capec-586.
This issue affects victor: before 8.0; CCure 9000: before 3.2; Victor Application Server: before 4.1. |
| Unauthenticated PHP Object Injection in Abelle <= 1.22 versions. |
| Unauthenticated PHP Object Injection in Advice <= 1.18.0 versions. |
| Subscriber PHP Object Injection in Export User Data <= 2.2.6 versions. |
| Author PHP Object Injection in Jeg Kit for Elementor <= 3.2.10 versions. |
| Unauthenticated PHP Object Injection in Adrena <= 1.2.14 versions. |
| Unauthenticated PHP Object Injection in Abogado <= 1.18 versions. |
| Unauthenticated PHP Object Injection in Agora <= 1.9 versions. |
| /misc/workspace/adhoc_connect_server, part of the Workspaces feature introduced in pgAdmin 4 9.0, when passed the id of an existing server, clones that server via Server.clone(), which copies every column from the source row, including user_id, shared, shared_username, and the stored credential fields password, save_password, and tunnel_password. When a non-owner triggered an adhoc connect against another user's (in practice, typically an administrator's) shared server, the clone inherited that user's ownership, shared flag, and stored database credentials verbatim. pgAdmin persisted this cross-tenant, credential-bearing server row before the connection was even attempted, so it survived even when the connection subsequently failed. The non-owner could then open the newly-owned clone and pgAdmin would connect using the source user's stored database password on the non-owner's behalf, granting the non-owner use of database credentials -- and whatever database privileges they confer -- that were never their own.
Fix forces the cloned adhoc record's ownership fields (user_id, shared, shared_username) and stored credential fields (password, save_password, tunnel_password) to belong to the calling user and be cleared/private before committing, regardless of the source server's ownership, sharing state, or stored credentials. A regression test asserts that an adhoc connect triggered by a non-owner against another user's shared server persists a row owned by the caller, not shared, and without the source's stored credentials.
This issue affects pgAdmin 4: from 9.0 before 9.17. |
