Latest News

### Impact The Markdown syntax is vulnerable to XSS through HTML. In particular, using Markdown syntax, it's possible for any user to embed Javascript code that will then be executed on the browser of any other user visiting either the document or the comment that contains it. In the instance that this code is executed by a user with admins or programming rights, this issue compromises the confidentiality, integrity and availability of the whole XWiki installation. To reproduce, on an instance where the CommonMark Markdown Syntax 1.2 extension is installed, log in as a user without script rights. Edit a document and set its syntax to Markdown. Then , add the content `<script>alert("XSS")</script>` and refresh the page. If an alert appears containing "XSS", then the instance is vulnerable. ### Patches This has been patched in version 8.9 of the CommonMark Markdown Syntax 1.2 extension. ### Workarounds We're not aware of any workaround except upgrading. ### References * https://jira....

### Impact A user who can access pages located in the XWiki space (by default, anyone) can access the page `XWiki.Authentication.Administration` and (unless an authenticator is set in `xwiki.cfg`) switch to another installed authenticator. Note that, by default, there is only one authenticator available (`Standard XWiki Authenticator`). So, if no authenticator extension was installed, it's not really possible to do anything for an attacker. Also, in most cases, if you have installed and are using an SSO authenticator (like OIDC or LDAP for example), the worst an attacker can do is break authentication by switching back to the standard authenticator (that's because it's impossible to login to a user which does not have a stored password, and that's usually what SSO authenticator produce). ### Patches This has been patched in XWiki 15.10.9 and XWiki 16.3.0RC1. ### Workarounds You can very easily fix this vulnerability in your instance through right configuration: * access the page...

### Impact Anyone can access the metadata of any attachment in the wiki using the wiki attachment REST endpoint. It's not filtering the result depending on current user rights, a not authenticated user could exploit this even in a totally private wiki. To reproduce: * remove view from guest on the whole wiki * logout * access http://127.0.0.1:8080/xwiki/rest/wikis/xwiki/attachments You get a list of attachments, while the expected result should be an empty list. ### Patches This vulnerability has been fixed in XWiki 14.10.22, 15.10.12, 16.7.0-rc-1 and 16.4.3. ### Workarounds We're not aware of any workaround except upgrading. ### 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) ### Attribution Issue reported by Lukas Monert.

Overview OpenFGA v1.8.10 or previous (Helm chart <= openfga-0.2.28, docker <= v.1.8.10) are vulnerable to authorization bypass when certain Check and ListObject calls are executed. Am I Affected? If you are using OpenFGA v1.8.10 or previous, specifically under the following conditions, you are affected by this authorization bypass vulnerability: - Calling Check API or ListObjects with an [authorization model](https://openfga.dev/docs/concepts#what-is-an-authorization-model) that has tuple cycle. - [Check query cache](https://github.com/openfga/openfga/blob/9b5974458b777707ed2a30ba6303699499e655ee/.config-schema.json#L528) is enabled, and - There are multiple check / list objects requests involving the tuple cycle within the check query TTL Fix Upgrade to v1.8.11. This upgrade is backwards compatible.

### Impact This issue allows an attacker who has compromised either the Elastic service or the extender plugin to cause denial of service of the scheduler. This is a privilege escalation, because Volcano users may run their Elastic service and extender plugins in separate pods or nodes from the scheduler. In the Kubernetes security model, node isolation is a security boundary, and as such an attacker is able to cross that boundary in Volcano's case if they have compromised either the vulnerable services or the pod/node in which they are deployed. The scheduler will become unavailable to other users and workloads in the cluster. The scheduler will either crash with an unrecoverable OOM panic or freeze while consuming excessive amounts of memory. ### Workarounds No

### Impact Attackers can deceive users into sending funds to an unintended address. ### Patches https://github.com/cryptocoinjs/base-x/pull/86

WordPress sites are under threat from a deceptive anti-malware plugin. Learn how this malware grants backdoor access, hides…

As the field of artificial intelligence (AI) continues to evolve at a rapid pace, new research has found how techniques that render the Model Context Protocol (MCP) susceptible to prompt injection attacks could be used to develop security tooling or identify malicious tools, according to a new report from Tenable. MCP, launched by Anthropic in November 2024, is a framework designed to connect

Fake emails pretending to come from the US Social Security Administration try to get targets to install ScreenConnect for remote access.

Retailer Acts Swiftly to Limit Threat as UK Retail Sector Faces Growing Digital Risks