Security
Headlines
HeadlinesLatestCVEs

Latest News

GHSA-4m32-cjv7-f425: AstrBot is vulnerable to RCE with hard-coded JWT signing keys

### Summary AstrBot uses a hard-coded JWT signing key, allowing attackers to execute arbitrary commands by installing a malicious plugin. ### Details AstrBot uses a [hard-coded JWT signing key](https://github.com/AstrBotDevs/AstrBot/blob/v3.5.16/astrbot/core/__init__.py), which allows attackers to bypass the authentication mechanism. Once bypassed, the attacker can install a Python plugin that will be imported [here](https://github.com/AstrBotDevs/AstrBot/blob/master/astrbot/dashboard/routes/plugin.py), enabling arbitrary command execution on the target host. ### Impact All publicly accessible AstrBot instances are vulnerable. For more information, please see: [CVE-2025-55449-AstrBot-RCE](https://github.com/Marven11/CVE-2025-55449-AstrBot-RCE)

ghsa
#vulnerability#git#rce#auth
GHSA-m8jr-fxqx-8xx6: Apollo Federation has Improper Enforcement of Access Control on Transitive Fields

# Summary A vulnerability in Apollo Federation's composition logic did not enforce that fields depending on protected data through `@requires` and/or `@fromContext` directives have the same access control requirements as the fields they reference. This allowed queries to access protected fields indirectly through their dependencies, bypassing access control checks. A fix to composition logic in Federation now enforces that dependent fields match the access control requirements from of the fields they reference. ## Details Apollo Federation allows users to specify [`@authenticated`, `@requiresScopes`, and `@policy` directives](https://www.apollographql.com/docs/graphos/routing/security/authorization#authorization-directives) to protect fields at the field level. The `@requires` directive allows a field to depend on data from other fields in the schema, and `@fromContext` allows a field to use values from the execution context. However, Apollo Router does not enforce access control requ...

GHSA-vv2v-pw69-8crf: Directus is Vulnerable to Stored Cross-site Scripting

### Summary A stored cross-site scripting (XSS) vulnerability exists that allows users with `upload files` and `edit item` permissions to inject malicious JavaScript through the Block Editor interface. Attackers can bypass Content Security Policy (CSP) restrictions by combining file uploads with iframe srcdoc attributes, resulting in persistent XSS execution. ### Details The vulnerability arises from insufficient sanitization in the Block Editor interface when processing JSON content containing HTML elements. The attack requires two permissions: - `upload files` - To upload malicious JavaScript files - `edit item` - To create or modify content with the Block Editor **Attack Vector:** 1. **JavaScript File Upload**: Attackers upload a malicious JavaScript file via the files endpoint, obtaining a file ID accessible through the assets directory 2. **Block Editor Exploitation**: Using a JSON field with Block Editor interface, attackers inject raw HTML containing an iframe with srcdoc ...

GHSA-9x5g-62gj-wqf2: Directus has Improper Permission Handling on Deleted Fields

### Summary Directus does not properly clean up field-level permissions when a field is deleted. If a new field with the same name is created later, the system automatically re-applies the old permissions, which can lead to unauthorized access. ### Details When a field is removed from a collection, its reference in the permissions table remains intact. This stale reference creates a security gap: if another field is later created using the same name, it inherits the outdated permission entry. This behavior can unintentionally grant roles access to data they should not be able to read or modify. The issue is particularly risky in multi-tenant or production environments, where administrators may reuse field names, assuming old permissions have been fully cleared. 1. Create a collection named test_collection. 2. Add a field called secret_field. 3. Assign a role with read permissions specifically tied to secret_field. 4. Remove the secret_field from the collection. 5. Create a ne...

Akira RaaS Targets Nutanix VMs, Threatens Critical Orgs

The Akira ransomware group has been experimenting with new tools, bugs, and attack surfaces, with demonstrated success in significant sectors.

GHSA-jj37-3377-m6vv: Duplicate Advisory: Nodemailer: Email to an unintended domain can occur due to Interpretation Conflict

## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-mm7p-fcc7-pg87. This link is maintained to preserve external references. ## Original Description A vulnerability was identified in the email parsing library due to improper handling of specially formatted recipient email addresses. An attacker can exploit this flaw by crafting a recipient address that embeds an external address within quotes. This causes the application to misdirect the email to the attacker's external address instead of the intended internal recipient. This could lead to a significant data leak of sensitive information and allow an attacker to bypass security filters and access controls.

GHSA-j4g7-v4m4-77px: ZITADEL is vulnerable to Account Takeover with deactivated Instance IdP

### Summary A vulnerability in ZITADEL's federation process allowed auto-linking users from external identity providers to existing users in ZITADEL even if the corresponding IdP was not active or if the organization did not allow federated authentication. ### Impact This vulnerability stems from the platform's failure to correctly check or enforce an organization's specific security settings during the authentication flow. An Organization Administrator can explicitly disable an IdP or disallow federation, but this setting was not being honored during the auto-linking process. This allowed an unauthenticated attacker to initiate a login using an IdP that should have been disabled for that organization. The platform would incorrectly validate the login and, based on a matching criteria, link the attacker's external identity to an existing internal user account. This may result in a full Account Takeover, bypassing the organization's mandated security controls. Note that accounts wi...

GHSA-fjh6-8679-9pch: Flowise does not Prevent Bypass of Password Confirmation - Unverified Password Change

### Summary Bypass of Password Confirmation - Unverified Password Change (authenticated change without current password) An authenticated user is allowed to change their account password without supplying the current password or any additional verification. The application does not verify the actor’s authority to perform that credential change (no current-password check, no authorization enforcement). An attacker who is merely authenticated (or who can trick or coerce an authenticated session) can set a new password and gain control of the account. (ATO - Account Takeover) ### Details Occurence - code: https://github.com/FlowiseAI/Flowise/blob/main/packages/ui/src/views/account/index.jsx#L278 Remote and physical scenarios can be considered. ### PoC **Repro steps:** 1. As logged in user https://cloud.flowiseai.com/account scroll down to 'Security' section 2. Change password to the new password 3. Notice Unverified Password Change (authenticated change without current password) **P...

GHSA-x39m-3393-3qp4: Flowise doesn't Prevent Bypass of Password Confirmation through Unverified Email Change (credentials)

### Summary Unverified Email Change - Email as part of Credential / Unverified Account Recovery Channel Change The application allows changing the account email address (used as a login identifier and/or password recovery address) without verifying the requester’s authority to make that change (no confirmation to the old email, no authentication step). Because email often functions as a credential or recovery channel, unverified email changes enable attackers to take over accounts by switching the account’s recovery/login address. ### Details Occurence - code: https://github.com/FlowiseAI/Flowise/blob/main/packages/ui/src/views/account/index.jsx#L211 Remote and physical scenarios can be considered. ### PoC **Repro steps:** 1. As logged in user https://cloud.flowiseai.com/account scroll down to 'Profile' section 2. Change email to the new email 3. Notice Unverified Password Change (authenticated change without current password) Later this email is needed as credentials to log in or...

New Security Tools Target Growing macOS Threats

A public dataset and platform-agnostic analysis tool aim to help organizations in the fight against Apple-targeted malware, which researchers say has lacked proper attention.