| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Harden-Runner is a CI/CD security agent that works like an EDR for GitHub Actions runners. In versions 2.15.1 and below, the Harden-Runner that allows bypass of the egress-policy: block network restriction using DNS queries over TCP. Egress policies are enforced on GitHub runners by filtering outbound connections at the network layer. When egress-policy: block is enabled with a restrictive allowed-endpoints list (e.g., only github.com:443), all non-compliant traffic should be denied. However, DNS queries over TCP, commonly used for large responses or fallback from UDP, are not adequately restricted. Tools like dig can explicitly initiate TCP-based DNS queries (+tcp flag) without being blocked. This vulnerability requires the attacker to already have code execution capabilities within the GitHub Actions workflow. The issue has been fixed in version 2.16.0. |
| Harden-Runner is a CI/CD security agent that works like an EDR for GitHub Actions runners. In versions 2.15.1 and below, a DNS over HTTPS (DoH) vulnerability allows attackers to bypass egress-policy: block network restrictions by tunneling exfiltrated data through permitted HTTPS endpoints like dns.google. The attack works by encoding sensitive data (e.g., the runner's hostname) as subdomains in DoH queries, which appear as legitimate HTTPS traffic to Harden-Runner's domain-based filtering but are ultimately forwarded to an attacker-controlled domain. This effectively enables data exfiltration without directly connecting to any blocked destination. Exploitation requires the attacker to already have code execution within the GitHub Actions workflow. The issue was fixed in version 2.16.0. |
| Missing Authorization (CWE-862) in Kibana’s server-side Detection Rule Management can lead to Unauthorized Endpoint Response Action Configuration (host isolation, process termination, and process suspension) via CAPEC-1 (Accessing Functionality Not Properly Constrained by ACLs). This requires an authenticated attacker with rule management privileges. |
| OpenEMR is a free and open source electronic health records and medical practice management application. Prior to 8.0.0.2, the module ACL function `AclMain::zhAclCheck()` only checks for the presence of any "allow" (user or group). It never checks for explicit "deny" (allowed=0). As a result, administrators cannot revoke access by setting a user or group to "deny"; if the user is in a group that has "allow," access is granted regardless of explicit denies. Version 8.0.0.2 fixes the issue. |
| OpenEMR is a free and open source electronic health records and medical practice management application. Prior to 8.0.0.2, an authorization bypass in the dated reminders log allows any authenticated non-admin user to view reminder messages belonging to other users, including associated patient names and free-text message content, by crafting a GET request with arbitrary user IDs in the `sentTo[]` or `sentBy[]` parameters. Version 8.0.0.2 fixes the issue. |
| OpenEMR is a free and open source electronic health records and medical practice management application. Prior to 8.0.0.2, an authorization bypass in the optional FaxSMS module (`oe-module-faxsms`) allows any authenticated OpenEMR user to invoke controller methods — including `getNotificationLog()`, which returns patient appointment data (PHI) — regardless of whether they hold the required ACL permissions. The `AppDispatch` constructor dispatches user-controlled actions and exits the process before any calling code can enforce ACL checks. Version 8.0.0.2 fixes the issue. |
| Discourse is an open-source discussion platform. Prior to versions 2026.3.0-latest.1, 2026.2.1, and 2026.1.2, requesting /posts/:id.json?version=X bypassed authorization checks on post revisions. The display_post method called post.revert_to directly without verifying whether the revision was hidden or if the user had permission to view edit history. This meant hidden revisions (intentionally concealed by staff) could be read by any user by simply enumerating version numbers. Starting in versions 2026.3.0-latest.1, 2026.2.1, and 2026.1.2, Discourse looks up the PostRevision and call guardian.ensure_can_see! before reverting, consistent with how the /posts/:id/revisions/:revision endpoint already authorizes access. No known workarounds are available. |
| Discourse is an open-source discussion platform. Prior to versions 2026.3.0-latest.1, 2026.2.1, and 2026.1.2, a type coercion issue in a post actions API endpoint allowed non-staff users to issue warnings to other users. Warnings are a staff-only moderation feature. The vulnerability required the attacker to be a logged-in user and to send a specifically crafted request. No data exposure or privilege escalation beyond the ability to create unauthorized user warnings was possible. Versions 2026.3.0-latest.1, 2026.2.1, and 2026.1.2 contain a patch. No known workarounds are available. |
| SQLBot is an intelligent data query system based on a large language model and RAG. Versions 1.5.0 and below contain a Stored Prompt Injection vulnerability that chains three flaws: a missing permission check on the Excel upload API allowing any authenticated user to upload malicious terminology, unsanitized storage of terminology descriptions containing dangerous payloads, and a lack of semantic fencing when injecting terminology into the LLM's system prompt. Together, these flaws allow an attacker to hijack the LLM's reasoning to generate malicious PostgreSQL commands (e.g., COPY ... TO PROGRAM), ultimately achieving Remote Code Execution on the database or application server with postgres user privileges. The issue is fixed in v1.6.0. |
| Discourse is an open-source discussion platform. Prior to versions 2026.3.0-latest.1, 2026.2.1, and 2026.1.2, a restriction bypass allows restricted post action counts to be disclosed to non-privileged users through a carefully crafted request. Versions 2026.3.0-latest.1, 2026.2.1, and 2026.1.2 contain a patch. No known workarounds are available. |
| Discourse is an open-source discussion platform. Versions prior to 2026.3.0-latest.1, 2026.2.1, and 2026.1.2 have a security flaw in the discourse-policy plugin which allowed a user with policy creation permission to gain membership access to any private/restricted groups. Once membership to a private/restricted group has been obtained, the user will be able to read private topics that only the group has access to. Versions 2026.3.0-latest.1, 2026.2.1, and 2026.1.2 contain a patch. As a workaround, review all policies for the use of `add-users-to-group` and temporarily remove the attribute from the policy. Alternatively, disable the discourse-policy plugin by disabling the `policy_enabled` site setting. |
| Discourse is an open-source discussion platform. Prior to versions 2026.3.0-latest.1, 2026.2.1, and 2026.1.2, users who do not belong to the allowed policy creation groups can create functional policy acceptance widgets in posts under the right conditions. Versions 2026.3.0-latest.1, 2026.2.1, and 2026.1.2 contain a patch. As a workaround, disable the discourse-policy plugin by disabling the `policy_enabled` site setting. |
| Discourse is an open-source discussion platform. Versions prior to 2026.3.0-latest.1, 2026.2.1, and 2026.1.2 have two authorization issues in the chat direct message API. First, when creating a direct message channel or adding users to an existing one, the `target_groups` parameter was passed directly to the user resolution query without checking group or member visibility for the acting user. An authenticated chat user could craft an API request with a known private/hidden group name and receive a channel containing that group's members, leaking their identities. Second, `can_chat?` only checked group membership, not the `chat_enabled` user preference. A chat-disabled user could create or query DM channels between other users via the direct messages API, potentially exposing private `last_message` content from the serialized channel response. Versions 2026.3.0-latest.1, 2026.2.1, and 2026.1.2 contain a patch. No known workarounds are available. |
| Discourse is an open-source discussion platform. Prior to versions 2026.3.0-latest.1, 2026.2.1, and 2026.1.2, moderators were able to see the first 40 characters of post edits in PMs and private categories. Versions 2026.3.0-latest.1, 2026.2.1, and 2026.1.2 contain a patch. No known workarounds are available. |
| Admidio is an open-source user management solution. In versions 5.0.0 through 5.0.6, the forum module in Admidio does not verify whether the current user has permission to delete forum topics or posts. Both the topic_delete and post_delete actions in forum.php only validate the CSRF token but perform no authorization check before calling delete(). Any authenticated user with forum access can delete any topic (with all its posts) or any individual post by providing its UUID. This is inconsistent with the save/edit operations, which properly check isAdministratorForum() and ownership before allowing modifications. Any logged-in user can permanently and irreversibly delete any forum topic (including all its posts) or any individual post by simply knowing its UUID (which is publicly visible in URLs), completely bypassing authorization checks. This issue has been fixed in version 5.0.7. |
| OpenClaw versions prior to 2026.2.25 fail to enforce sender authorization checks for interactive callbacks including block_action, view_submission, and view_closed in shared workspace deployments. Unauthorized workspace members can bypass allowFrom restrictions and channel user allowlists to enqueue system-event text into active sessions. |
| OpenClaw versions prior to 2026.2.26 contain an authorization bypass vulnerability where DM pairing-store identities are incorrectly treated as group allowlist identities when dmPolicy=pairing and groupPolicy=allowlist. Remote attackers can send messages and reactions as DM-paired identities without explicit groupAllowFrom membership to bypass group sender authorization checks. |
| n authorization flaw in Foreman's GraphQL API allows low-privileged users to access metadata beyond their assigned permissions. Unlike the REST API, which correctly enforces access controls, the GraphQL endpoint does not apply proper filtering, leading to an authorization bypass. |
| A flaw was found in Quarkus. This issue occurs when receiving a request over websocket with no role-based permission specified on the GraphQL operation, Quarkus processes the request without authentication despite the endpoint being secured. This can allow an attacker to access information and functionality outside of normal granted API permissions. |
| A flaw was found in the Linux kernel's TUN/TAP functionality. This issue could allow a local user to bypass network filters and gain unauthorized access to some resources. The original patches fixing CVE-2023-1076 are incorrect or incomplete. The problem is that the following upstream commits - a096ccca6e50 ("tun: tun_chr_open(): correctly initialize socket uid"), - 66b2c338adce ("tap: tap_open(): correctly initialize socket uid"), pass "inode->i_uid" to sock_init_data_uid() as the last parameter and that turns out to not be accurate. |
