CVE-2026-9560 is a critical privilege escalation vulnerability in OpenVPN Connect versions 3.5.1 through 3.8.1 on macOS. It allows an attacker with local access to execute arbitrary commands with elevated privileges via a local inter-process communication (IPC) channel in the background service. The vulnerability is related to improper handling of IPC leading to command injection. No official patch or remediation guidance has been provided yet, and no known exploits are reported in the wild.
CVE-2026-34853 is a high-severity permission bypass vulnerability in the Location-Based Services (LBS) module of Huawei HarmonyOS versions 4.0.0 through 4.3.1. It involves a privilege context switching error (CWE-270) that may allow an attacker with high privileges and user interaction to bypass permissions, potentially impacting system availability. The vulnerability has a CVSS 3.1 base score of 7.7, indicating significant risk. No official patch or remediation guidance is currently available from the vendor.
FreePBX is an open-source web-based graphical user interface (GUI) that manages Asterisk. Prior to 17.0.5 and 16.0.17, FreePBX module api (PBX API) is vulnerable to privilege escalation by authenticated users with REST/GraphQL API access. This vulnerability allows an attacker to forge a valid JWT with full access to the REST and GraphQL APIs on a FreePBX that they've already connected to, possibly as a lower privileged user. The JWT is signed using the api-oauth.key private key. An attacker can generate their own token if they possess this key (e.g., by accessing an affected instance), and specify any scopes they wish (e.g., rest, gql), bypassing traditional authorization checks. However, FreePBX enforces that the jti (JWT ID) claim must exist in the database (api_access_tokens table in the asterisk MySQL database) in order for the token to be accepted. Therefore, the attacker must know a jti value that already exists on the target instance. This vulnerability is fixed in 17.0.5 and 16.0.17.
System call entry on Cortex M (and possibly R and A, but I think not) has a race which allows very practical privilege escalation for malicious userspace processes.
A Privilege Context Switching Error (CWE-270) in the Command Center Server could allow a privileged Operator with high level access in one Division to perform limited privileged activities across the Division boundary.
This issue affects Command Centre Server:
9.30 prior to 9.30.1874 (MR1), 9.20 prior to 9.20.2337 (MR3), 9.10 prior to 9.10.3194 (MR6), 9.00 prior to 9.00.3371 (MR7), all versions of 8.90 and prior.
XWiki is a generic wiki platform. When a user without script right creates a document with an `XWiki.Notifications.Code.NotificationEmailRendererClass` object, and later an admin edits and saves that document, the email templates in this object will be used for notifications. No malicious code can be executed, though, as while these templates allow Velocity code, the existing generic analyzer already warns admins before editing Velocity code. The main impact would thus be to send spam, e.g., with phishing links to other users or to hide notifications about other attacks. Note that warnings before editing documents with dangerous properties have only been introduced in XWiki 15.9, before that version, this was a known issue and the advice was simply to be careful. This has been patched in XWiki 16.10.2, 16.4.7 and 15.10.16 by adding an analysis for the respective XClass properties.
XWiki is a generic wiki platform. Any user with edit right on a page (could be the user's profile) can execute code (Groovy, Python, Velocity) with programming right by defining a wiki macro. This allows full access to the whole XWiki installation. The main problem is that if a wiki macro parameter allows wiki syntax, its default value is executed with the rights of the author of the document where it is used. This can be exploited by overriding a macro like the children macro that is used in a page that has programming right like the page XWiki.ChildrenMacro and thus allows arbitrary script macros. This vulnerability has been patched in XWiki 16.4.7, 16.10.3 and 17.0.0 by executing wiki parameters with the rights of the wiki macro's author when the parameter's value is the default value.