Latest News
# Summary pREST provides a simple way for users to expose access their database via a REST-full API. The project is implemented using the Go programming language and is designed to expose access to Postgres database tables. During an independent review of the project, Doyensec engineers found that SQL injection is a systemic problem in the current implementation (version `v2.0.0-rc2`). Even though there are several instances of attempts to sanitize user input and mitigate injection attempts, we have found that on most code-paths, the protection is faulty or non-existent. ## Core Endpoints The main functionality providing REST operations on the data stored in the Postgres database is exposed via the following endpoints: - `GET /{database}/{schema}/{table}` - `POST /{database}/{schema}/{table}` - `PUT|PATCH /{database}/{schema}/{table}` - `DELETE /{database}/{schema}/{table}` Handlers for the above endpoints execute very similar logic. At a high-level they: 1. Perform authenticati...
An XSS issue was reported in the MCP Inspector local development tool when connecting to an untrusted remote MCP server with a malicious redirect URI. This could be leveraged to interact directly with the inspector proxy to trigger arbitrary command execution. Users are advised to update to 0.16.6 to resolve this issue. Thank you to the following researchers for their reports and contributions: * Raymond (Veria Labs) * Gavin Zhong, [superboyzjc@gmail.com](mailto:superboyzjc@gmail.com) & Shuyang Wang, [swang@obsidiansecurity.com](mailto:swang@obsidiansecurity.com).
The combined company will help customers separate data ingestion from SIEM to improve threat detection and response.
### Impact The blog application in XWiki allowed remote code execution for any user who has edit right on any page. Normally, these are all logged-in users as they can edit their own user profile. To exploit, it is sufficient to add an object of type `Blog.BlogPostClass` to any page and to add some script macro with the exploit code to the "Content" field of that object. ### Patches The vulnerability has been patched in the blog application version 9.14 by executing the content of blog posts with the rights of the appropriate author. ### Workarounds We're not aware of any workarounds. ### Resources * https://jira.xwiki.org/browse/BLOG-191 * https://github.com/xwiki-contrib/application-blog/commit/b98ab6f17da3029576f42d12b4442cd555c7e0b4
A threat actor is using a sophisticated EDR-killing malware tool in a campaign to maintain long-term, persistent access on Windows systems.
### Summary The OAuth client creation and update endpoints of the Fides Webserver API do not properly authorize scope assignment. This allows highly privileged users with `client:create` or `client:update` permissions to escalate their privileges to owner-level. ### Details When creating or updating OAuth clients, the API validates only that requested scopes exist in the system registry. It does not verify that the requester already possesses the scopes they are assigning, allowing these users to assign arbitrary scopes to OAuth clients. ### Impact This allows contributor-level users to escalate to owner-equivalent privileges, gaining access to user management, system configuration, and permission assignment capabilities they should not possess. ### Patches The vulnerability has been patched in Fides version `2.69.1`. Users are advised to upgrade to this version or later to secure their systems against this threat. ### Workarounds There are no workarounds. ### Risk Level This vuln...
### Summary The Fides Webserver API's built-in IP-based rate limiting is ineffective in environments with CDNs, proxies or load balancers. The system incorrectly applies rate limits based on directly connected infrastructure IPs rather than client IPs, and stores counters in-memory rather than in a shared store. This allows attackers to bypass intended rate limits and potentially cause denial of service. This vulnerability only affects deployments relying on Fides's built-in rate limiting for protection. Deployments using external rate limiting solutions (WAFs, API gateways, etc.) are not affected. ### Details The vulnerability has two components: 1. Rate limiting uses the immediate connection source IP instead of the actual client IP 2. Rate limit counters are maintained in-memory per container rather than in a shared store In production environments, these issues allow clients to exceed intended rate limits and enable attackers to trigger rate limits on infrastructure IPs, caus...
### Summary The Fides Admin UI login endpoint relies on a general IP-based rate limit for all API traffic and lacks specific anti-automation controls designed to protect against brute-force attacks. This could allow attackers to conduct credential testing attacks, such as credential stuffing or password spraying, which poses a risk to accounts with weak or previously compromised passwords. ### Details Fides uses a configurable, system-wide rate limit to control traffic from any single IP address. Because this single limit must be set high enough to accommodate endpoints that receive a large volume of legitimate traffic, it offers only weak protection for the login endpoint. The system is not equipped with more advanced protections tailored specifically for authentication ### Impact Although password complexity requirements and the global rate limit make a traditional brute-force attack against a single account difficult, the lack of authentication-specific protections exposes Fid...
The breach kickstarted a massive supply chain attack that led to the compromise of hundreds of Salesforce instances through stolen OAuth tokens.
### Summary Admin UI user password changes in Fides do not invalidate active user sessions, creating a vulnerability chaining opportunity where attackers who have obtained session tokens through other attack vectors (such as XSS) can maintain access even after password reset. This issue is not directly exploitable on its own and requires a prerequisite vulnerability to obtain valid session tokens in the first place. ### Details Fides uses encrypted authentication tokens with extended expiration periods. When a password is changed via password reset endpoints, the system updates the password hash in the database but does not invalidate existing client sessions or tokens. The authentication system validates tokens based on their cryptographic integrity and expiration time, not against the current password state. The frontend application stores authentication state in browser local storage, which persists across browser sessions until explicit logout or natural token expiration. This...