#java

New research by Infoblox Threat Intel exposes a hidden alliance between major cybercrime groups like VexTrio and seemingly…

### Summary Any project that uses Protobuf pure-Python backend to parse untrusted Protocol Buffers data containing an arbitrary number of **recursive groups**, **recursive messages** or **a series of [`SGROUP`](https://protobuf.dev/programming-guides/encoding/#groups) tags** can be corrupted by exceeding the Python recursion limit. Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team [[email protected]](mailto:[email protected]) Affected versions: This issue only affects the [pure-Python implementation](https://github.com/protocolbuffers/protobuf/tree/main/python#implementation-backends) of protobuf-python backend. This is the implementation when `PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=python` environment variable is set or the default when protobuf is used from Bazel or pure-Python PyPi wheels. CPython PyPi wheels do not use pure-Python by default. This is a Python variant of a [previous issue affecting protobuf-java](https://github.com/protocolbuffers/...

Path traversal vulnerability with the downloading and installation of Xuggler in Liferay Portal 7.0.0 through 7.4.3.4, and Liferay DXP 7.4 GA, 7.3 GA through update 34, and older unsupported versions allows remote attackers to (1) add files to arbitrary locations on the server and (2) download and execute arbitrary files from the download server via the `_com_liferay_server_admin_web_portlet_ServerAdminPortlet_jarName` parameter.

### Impact The title of every single page whose reference is known can be accessed through the REST API as long as an XClass with a page property is accessible, this is the default for an XWiki installation. This allows an attacker to get titles of pages whose reference is known, one title per request. This doesn't affect fully [private wikis](https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Access%20Rights/#HPrivateWiki) as the REST endpoint checks access rights on the XClass definition. The impact on confidentiality depends on the strategy for page names. By default, page names match the title, so the impact should be low but if page names are intentionally obfuscated because the titles are sensitive, the impact could be high. ### Patches This has been fixed in XWiki 16.4.7, 16.10.3 and 17.0.0 by adding access control checks before getting the title of any page. ### Workarounds We're not aware of any workarounds.

### Impact 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 and thus impacts its confidentiality, integrity and availability. 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. The full reproduction steps can be found in the [original issue](https://jira.xwiki.org/browse/XWIKI-22760). ### Patches 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. ### Workarounds We're not aware...

### Impact When editing content that contains "dangerous" macros like malicious script macros that were authored by a user with fewer rights, XWiki warns about the execution of these macros since XWiki 15.9RC1. These required rights analyzers that trigger these warnings are incomplete, allowing an attacker to hide malicious content. For most macros, the existing analyzers don't consider non-lowercase parameters. Further, most macro parameters that can contain XWiki syntax like titles of information boxes weren't analyzed at all. Similarly, the "source" parameters of the content and context macro weren't anylzed even though they could contain arbitrary XWiki syntax. In the worst case, this could allow a malicious to add malicious script macros including Groovy or Python macros to a page that are then executed after another user with programming righs edits the page, thus allowing remote code execution. ### Patches The required rights analyzers have been made more robust and extended to...

### Impact Pages can gain script or programming rights when they contain a link and the target of the link is renamed or moved. This might lead to execution of scripts contained in xobjects that should have never been executed. This vulnerability affects all version of XWiki since 8.2 and 7.4.5. ### Patches The patch consists in only setting the `originalMetadataAuthor` when performing such change, so that it's displayed in the history but it has no impact on the right evaluation (i.e. the original author of the changes is still used for right computation). This patch has been applied on XWiki 16.4.7, 17.1.0RC1, 16.10.4. ### Workarounds There's no workaround for this vulnerability, except preventing to perform any refactoring operation with users having more than edit rights. Administrators are strongly advised to upgrade. If not possible, the patch only impacts module `xwiki-platform-refactoring-default` so it's possible to apply the commit and rebuild and deploy only that mo...

Cybersecurity researchers are calling attention to a "large-scale campaign" that has been observed compromising legitimate websites with malicious JavaScript injections. According to Palo Alto Networks Unit 42, these malicious injects are obfuscated using JSFuck, which refers to an "esoteric and educational programming style" that uses only a limited set of characters to write and execute code.

### Description In Spring Framework, versions 6.0.x as of 6.0.5, versions 6.1.x and 6.2.x, an application is vulnerable to a reflected file download (RFD) attack when it sets a “Content-Disposition” header with a non-ASCII charset, where the filename attribute is derived from user-supplied input. Specifically, an application is vulnerable when all the following are true: - The header is prepared with `org.springframework.http.ContentDisposition`. - The filename is set via `ContentDisposition.Builder#filename(String, Charset)`. - The value for the filename is derived from user-supplied input. - The application does not sanitize the user-supplied input. - The downloaded content of the response is injected with malicious commands by the attacker (see RFD paper reference for details). An application is not vulnerable if any of the following is true: - The application does not set a “Content-Disposition” response header. - The header is not prepared with `org.spri...

Late last year, security researchers made a startling discovery: Kremlin-backed disinformation campaigns were bypassing moderation on social media platforms by leveraging the same malicious advertising technology that powers a sprawling ecosystem of online hucksters and website hackers. A new report on the fallout from that investigation finds this dark ad tech industry is far more resilient and incestuous than previously known.