#rce

### 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...

Microsoft has released patches to fix 67 security flaws, including one zero-day bug in Web Distributed Authoring and Versioning (WEBDAV) that it said has come under active exploitation in the wild. Of the 67 vulnerabilities, 11 are rated Critical and 56 are rated Important in severity. This includes 26 remote code execution flaws, 17 information disclosure flaws, and 14 privilege escalation

Microsoft today released security updates to fix at least 67 vulnerabilities in its Windows operating systems and software. Redmond warns that one of the flaws is already under active attack, and that software blueprints showing how to exploit a pervasive Windows bug patched this month are now public.

June 2025 Patch Tuesday fixes 66 bugs, including a zero-day in WebDAV. Update Windows, Office, and more now to block active threats.

The bug is one of 66 disclosed and patched today by Microsoft as part of its June 2025 Patch Tuesday set of security vulnerability fixes.

June Microsoft Patch Tuesday. A total of 81 vulnerabilities, roughly the same as in May. Among them, 15 vulnerabilities were added between the May and June MSPT. There are 3 vulnerabilities with signs of exploitation in the wild: 🔻 RCE – WEBDAV (CVE-2025-33053). The vulnerability is related to Internet Explorer mode in Microsoft Edge and […]

Microsoft has released its monthly security update for June 2025, which includes 66 vulnerabilities affecting a range of products, including 10 that Microsoft marked as “critical.”

A possible security vulnerability has been identified in Apache Kafka. This requires access to a alterConfig to the cluster resource, or Kafka Connect worker, and the ability to create/modify connectors on it with an arbitrary Kafka client SASL JAAS config and a SASL-based security protocol, which has been possible on Kafka clusters since Apache Kafka 2.0.0 (Kafka Connect 2.3.0). When configuring the broker via config file or AlterConfig command, or connector via the Kafka Kafka Connect REST API, an authenticated operator can set the `sasl.jaas.config` property for any of the connector's Kafka clients to "com.sun.security.auth.module.LdapLoginModule", which can be done via the `producer.override.sasl.jaas.config`, `consumer.override.sasl.jaas.config`, or `admin.override.sasl.jaas.config` properties. This will allow the server to connect to the attacker's LDAP server and deserialize the LDAP response, which the attacker can use to execute java deserialization gadget chains on the Kafka ...

In CVE-2023-25194, we announced the RCE/Denial of service attack via SASL JAAS JndiLoginModule configuration in Kafka Connect API. But not only Kafka Connect API is vulnerable to this attack, the Apache Kafka brokers also have this vulnerability. To exploit this vulnerability, the attacker needs to be able to connect to the Kafka cluster and have the AlterConfigs permission on the cluster resource. Since Apache Kafka 3.4.0, we have added a system property ("-Dorg.apache.kafka.disallowed.login.modules") to disable the problematic login modules usage in SASL JAAS configuration. Also by default "com.sun.security.auth.module.JndiLoginModule" is disabled in Apache Kafka 3.4.0, and "com.sun.security.auth.module.JndiLoginModule,com.sun.security.auth.module.LdapLoginModule" is disabled by default in in Apache Kafka 3.9.1/4.0.0