Latest News
The Profile widget in Liferay Portal 7.4.0 through 7.4.3.111, and older unsupported versions, and Liferay DXP 2023.Q4.0 through 2023.Q4.5, 2023.Q3.1 through 2023.Q3.8, 7.4 GA through update 92, and older unsupported versions uses a user’s name in the “Content-Disposition” header, which allows remote authenticated users to change the file extension when a vCard file is downloaded.
These are exciting times for AI. Enterprises are blending AI capabilities with enterprise data to deliver better outcomes for employees, customers, and partners. But as organizations weave AI deeper into their systems, that data and infrastructure also become more attractive targets for cybercriminals and other adversaries.Generative AI (gen AI), in particular, introduces new risks by significantly expanding an organization’s attack surface. That means enterprises must carefully evaluate potential threats, vulnerabilities, and the risks they bring to business operations. Deploying AI with a
### Summary The web UI for SillyTavern is susceptible to DNS rebinding, allowing attackers to perform actions like install malicious extensions, read chats, inject arbitrary HTML for phishing, etc. ### Details DNS rebinding is a method to bypass the CORS policies by tricking the browser into resolving something like `127.0.0.1` for a site's DNS address. This allows anybody to get remote access to anyone's SillyTavern instance **without** it being exposed, just by visiting a website. ### PoC 1. Host the PoC HTML file on a `/rebind.html` endpoint (or any other endpoint) on a web server on port 8000 2. Go to https://lock.cmpxchg8b.com/rebinder.html and input your IP address (A) to rebind to 127.0.0.1 (B) 3. Replace the URL in the HTML with the returned URL on the site 4. Go to `http://[URL]:8000/rebind.html` in firefox or on any mobile browser if you're using termux 5. Check the developer tools console. It should return all of the data Here is the PoC code: ```html <!DOCTYPE html> <...
While testing Litestar's RateLimitMiddleware, it was discovered that rate limits can be completely bypassed by manipulating the X-Forwarded-For header. This renders IP-based rate limiting ineffective against determined attackers. ## The Problem Litestar's RateLimitMiddleware uses `cache_key_from_request()` to generate cache keys for rate limiting. When an X-Forwarded-For header is present, the middleware trusts it unconditionally and uses its value as part of the client identifier. Since clients can set arbitrary X-Forwarded-For values, each different spoofed IP creates a separate rate limit bucket. An attacker can rotate through different header values to avoid hitting any single bucket's limit. Looking at the relevant code in `litestar/middleware/rate_limit.py` around [line 127](https://github.com/litestar-org/litestar/blob/26f20ac6c52de2b4bf81161f7560c8bb4af6f382/litestar/middleware/rate_limit.py#L127), there's no validation of proxy headers or configuration for trusted proxies....
### Impact The REST search URL is vulnerable to HQL injection via the `orderField` parameter. The specified value is added twice in the query, though, once in the field list for the select and once in the order clause, so it's not that easy to exploit. The part of the query between the two fields can be enclosed in single quotes to effectively remove them, but the query still needs to remain valid with the query two times in it. For example, with the following `orderField` parameter: ``` doc.fullName%20from%20XWikiDocument%20as%20doc%20where%20%24%24%3D'%24%24%3Dconcat(chr(61)%2Cchr(39))%20and%20version()%7C%7Cpg_sleep(1)%3Dversion()%7C%7Cpg_sleep(1)%20and%20(1%3D1%20or%20%3F%3D%3F%20or%20%3F%3D%3F%20or%20%3F%3D%3F%20or%20%3F%3D%3F%20or%20%3F%3D%3F)%20--%20comment'%20or%20a%3D'%20order%20by%20doc.fullName ``` See the following error: ``` QuerySyntaxException: unexpected token: $$ near line 1, column 518 [select distinct doc.fullName, doc.space, doc.name, doc.language, doc.doc.fullN...
A threat actor purporting to be from the Libyan Navy's Office of Protocol targeted Brazil's military earlier this year using the rare tactic.
The infamous Clop gang has targeted a wide range of Oracle E-Business Suite customers using a newly disclosed zero-day vulnerability.
The HTMLSectionSplitter class in langchain-text-splitters is vulnerable to XML External Entity (XXE) attacks due to unsafe XSLT parsing. This vulnerability arises because the class allows the use of arbitrary XSLT stylesheets, which are parsed using lxml.etree.parse() and lxml.etree.XSLT() without any hardening measures. In lxml versions up to 4.9.x, external entities are resolved by default, allowing attackers to read arbitrary local files or perform outbound HTTP(S) fetches. In lxml versions 5.0 and above, while entity expansion is disabled, the XSLT document() function can still read any URI unless XSLTAccessControl is applied. This vulnerability allows remote attackers to gain read-only access to any file the LangChain process can reach, including sensitive files such as SSH keys, environment files, source code, or cloud metadata. No authentication, special privileges, or user interaction are required, and the issue is exploitable in default deployments that enable custom XSLT.
ESET warns of fake Signal and ToTok apps spreading Android spyware in the UAE, stealing contacts, messages, and chat backups from users.
### Impact Anyone with VIEW access to a user profile can create a token for that user. If that XWiki instance is configured to allow token authentication, it allows authentication with any user (since users are very commonly viewable, at least to other registered users). ### Patches Version 2.18.2. ### Workarounds The only workaround is to disable token access. ### References * https://jira.xwiki.org/browse/OIDC-240 * https://github.com/xwiki-contrib/oidc/commit/d90d717172283aaa96bb5bb44e357f910ae64adb ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki.org](https://jira.xwiki.org/) * Email us at [Security Mailing List](mailto:security@xwiki.org)