| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| XWiki Commons are technical libraries common to several other top level XWiki projects. There was no check in the author of a JavaScript xobject or StyleSheet xobject added in a XWiki document, so until now it was possible for a user having only Edit Right to create such object and to craft a script allowing to perform some operations when executing by a user with appropriate rights. This has been patched in XWiki 14.9-rc-1 by only executing the script if the author of it has Script rights. |
| XWiki Commons are technical libraries common to several other top level XWiki projects. The Livetable Macro wasn't properly sanitizing column names, thus allowing the insertion of raw HTML code including JavaScript. This vulnerability was also exploitable via the Documents Macro that is included since XWiki 3.5M1 and doesn't require script rights, this can be demonstrated with the syntax `{{documents id="example" count="5" actions="false" columns="doc.title, before<script>alert(1)</script>after"/}}`. Therefore, this can also be exploited by users without script right and in comments. With the interaction of a user with more rights, this could be used to execute arbitrary actions in the wiki, including privilege escalation, remote code execution, information disclosure, modifying or deleting content. This has been patched in XWiki 14.9, 14.4.6, and 13.10.10.
|
| XWiki Commons are technical libraries common to several other top level XWiki projects. Rights added to a document are not taken into account for viewing it once it's deleted. Note that this vulnerability only impact deleted documents that where containing view rights: the view rights provided on a space of a deleted document are properly checked. The problem has been patched in XWiki 14.10 by checking the rights of current user: only admin and deleter of the document are allowed to view it. |
| XWiki Commons are technical libraries common to several other top level XWiki projects. It is possible to bypass the existing security measures put in place to avoid open redirect by using a redirect such as `//mydomain.com` (i.e. omitting the `http:`). It was also possible to bypass it when using URL such as `http:/mydomain.com`. The problem has been patched on XWiki 13.10.10, 14.4.4 and 14.8RC1.
|
| XWiki Commons are technical libraries common to several other top level XWiki projects. Any user with view rights on commonly accessible documents including the legacy notification activity macro can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation. The root cause is improper escaping of the macro parameters of the legacy notification activity macro. This macro is installed by default in XWiki. The vulnerability can be exploited via every wiki page that is editable including the user's profile, but also with just view rights using the HTMLConverter that is part of the CKEditor integration which is bundled with XWiki. The vulnerability has been patched in XWiki 13.10.11, 14.4.7 and 14.10.
|
| XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. Any user with the right to add an object on a page can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation. The root cause is improper escaping of the styles properties `FlamingoThemesCode.WebHome`. This page is installed by default. The vulnerability has been patched in XWiki versions 13.10.11, 14.4.7 and 14.10. |
| XWiki Commons are technical libraries common to several other top level XWiki projects. Any user with view rights `WikiManager.DeleteWiki` can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation. The root cause is improper escaping of the `wikiId` url parameter. The problem has been patched on XWiki 13.10.11, 14.4.7, and 14.10. |
| XWiki Commons are technical libraries common to several other top level XWiki projects. Any user with view rights on commonly accessible documents can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation. The root cause is improper escaping of the `documentTree` macro parameters in This macro is installed by default in `FlamingoThemesCode.WebHome`. This page is installed by default. The vulnerability has been patched in XWiki 13.10.11, 14.4.7 and 14.10. |
| XWiki Commons are technical libraries common to several other top level XWiki projects. Any user with view rights on commonly accessible documents including the notification preferences macros can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation. The root cause is improper escaping of the user parameter of the macro that provide the notification filters. These macros are used in the user profiles and thus installed by default in XWiki. The vulnerability has been patched in XWiki 13.10.11, 14.4.7 and 14.10. |
| XWiki Commons are technical libraries common to several other top level XWiki projects. Any user with edit rights can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation. The root cause is improper escaping of the included pages in the included documents edit panel. The problem has been patched on XWiki 14.4.7, and 14.10. |
| XWiki Commons are technical libraries common to several other top level XWiki projects. Any user with edit rights can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation. The root cause is improper escaping of the included pages in the IncludedDocuments panel. The problem has been patched on XWiki 14.4.7, and 14.10. |
| XWiki Commons are technical libraries common to several other top level XWiki projects. It was possible to inject some code using the URL of authenticated endpoints. This problem has been patched on XWiki 13.10.11, 14.4.7 and 14.10. |
| An Exposure of Resource to Wrong Sphere vulnerability in the Packet Forwarding Engine (PFE) of Juniper Networks Junos OS on SRX 300 Series allows an unauthenticated, adjacent attacker to cause a Denial of Service (DoS).
Specific valid link-local traffic is not blocked on ports in STP blocked state but is instead sent to the control plane of the device. This leads to excessive resource consumption and in turn severe impact on all control and management protocols of the device.
This issue affects Juniper Networks Junos OS:
* 21.2 version 21.2R3-S3 and later versions earlier than 21.2R3-S6;
* 22.1 version 22.1R3 and later versions earlier than 22.1R3-S4;
* 22.2 version
22.2R2
and later versions earlier than 22.2R3-S2;
* 22.3 version
22.3R2
and later versions earlier than 22.3R3-S1;
* 22.4 versions earlier than 22.4R2-S2, 22.4R3;
* 23.2 versions earlier than 23.2R1-S1, 23.2R2.
This issue does not affect Juniper Networks Junos OS 21.4R1 and later versions of 21.4. |
| OpenZeppelin Contracts is a library for smart contract development. By frontrunning the creation of a proposal, an attacker can become the proposer and gain the ability to cancel it. The attacker can do this repeatedly to try to prevent a proposal from being proposed at all. This impacts the `Governor` contract in v4.9.0 only, and the `GovernorCompatibilityBravo` contract since v4.3.0. This problem has been patched in 4.9.1 by introducing opt-in frontrunning protection. Users are advised to upgrade. Users unable to upgrade may submit the proposal creation transaction to an endpoint with frontrunning protection as a workaround. |
| An Improper Validation of Syntactic Correctness of Input vulnerability in the Routing Protocol Daemon (rpd) of Juniper Networks Junos OS and Junos OS Evolved allows a network-based, unauthenticated attacker to cause a Denial of Service (DoS).
If a BGP update is received over an established BGP session which contains a tunnel encapsulation attribute with a specifically malformed TLV, rpd will crash and restart.
This issue affects Juniper Networks
Junos OS:
* 20.4 versions 20.4R1 and later versions earlier than 20.4R3-S9;
* 21.2 versions earlier than 21.2R3-S7;
* 21.3 versions earlier than 21.3R3-S5;
* 21.4 versions earlier than 21.4R3-S5;
* 22.1 versions earlier than 22.1R3-S4;
* 22.2 versions earlier than 22.2R3-S3;
* 22.3 versions earlier than 22.3R3-S1;
* 22.4 versions earlier than 22.4R3;
* 23.2 versions earlier than 23.2R1-S2, 23.2R2;
Junos OS Evolved:
* 20.4-EVO versions 20.4R1-EVO and later versions earlier than 20.4R3-S9-EVO;
* 21.2-EVO versions earlier than 21.2R3-S7-EVO;
* 21.3-EVO versions earlier than 21.3R3-S5-EVO;
* 21.4-EVO versions earlier than 21.4R3-S5-EVO;
* 22.1-EVO versions earlier than 22.1R3-S4-EVO;
* 22.2-EVO versions earlier than 22.2R3-S3-EVO;
* 22.3-EVO versions earlier than 22.3R3-S1-EVO;
* 22.4-EVO versions earlier than 22.4R3-EVO;
* 23.2-EVO versions earlier than 23.2R1-S2-EVO, 23.2R2-EVO;
This issue does not affect Juniper Networks
* Junos OS versions earlier than 20.4R1;
* Junos OS Evolved versions earlier than 20.4R1-EVO.
This is a related but separate issue than the one described in JSA79095. |
| Archery is an open source SQL audit platform. The Archery project contains multiple SQL injection vulnerabilities, that may allow an attacker to query the connected databases. Affected versions are subject to SQL injection in the `sql_api/api_workflow.py` endpoint `ExecuteCheck` which passes unfiltered input to the `explain_check` method in `sql/engines/oracle.py`. User input coming from the `db_name` parameter value in the `api_workflow.py` `ExecuteCheck` endpoint is passed through the `oracle.py` `execute_check` method and to the `explain_check` method for execution. Each of these issues may be mitigated by escaping user input or by using prepared statements when executing SQL queries. This issue is also indexed as `GHSL-2022-103`. |
| Crafted Binder Request Causes Heap UAF in MediaServer |
| Archery is an open source SQL audit platform. The Archery project contains multiple SQL injection vulnerabilities, that may allow an attacker to query the connected databases. Affected versions are subject to multiple SQL injections in the `sql_api/api_workflow.py` endpoint `ExecuteCheck`. User input coming from the `db_name` parameter value and the `full_sql` parameter value in the `api_workflow.py` `ExecuteCheck` endpoint is passed to the methods that follow in given SQL engine implementations, which concatenate user input unsafely into a SQL query and afterwards pass it to the `query` method of each database engine for execution. The affected methods are `execute_check` in `sql/engines/clickhouse.py` which concatenates input which is passed to execution on the database in the `sql/engines/clickhouse.py` `query` method, `execute_check` in `sql/engines/goinception.py`which concatenates input which is passed to execution on the database in the `sql/engines/goinception.py` `query` method, `execute_check` in `sql/engines/oracle.py`which passes unsafe user input into the `object_name_check` method in `sql/engines/oracle.py` which in turn is passed to execution on the database in the `sql/engines/oracle.py` `query` method. Each of these issues may be mitigated by escaping user input or by using prepared statements when executing SQL queries. This issue is also indexed as `GHSL-2022-102`. |
| Archery is an open source SQL audit platform. The Archery project contains multiple SQL injection vulnerabilities, that may allow an attacker to query the connected databases. Affected versions are subject to SQL injection in the `sql/instance.py` endpoint's `describe` method. In several cases, user input coming from the `tb_name` parameter value, the `db_name` parameter value or the `schema_name` value in the `sql/instance.py` `describe` endpoint is passed to the `describe_table` methods in given SQL engine implementations, which concatenate user input unsafely into a SQL query and afterwards pass it to the `query` method of each database engine for execution. Please take into account that in some cases all three parameter values are concatenated, in other only one or two of them. The affected methods are: `describe_table` in `sql/engines/clickhouse.py`which concatenates input which is passed to execution on the database in the `query` method in `sql/engines/clickhouse.py`, `describe_table` in `sql/engines/mssql.py` which concatenates input which is passed to execution on the database in the `query` methods in `sql/engines/mssql.py`, `describe_table` in `sql/engines/mysql.py`which concatenates input which is passed to execution on the database in the `query` method in `sql/engines/mysql.py`, `describe_table` in `sql/engines/oracle.py` which concatenates input which is passed to execution on the database in the `query` methods in `sql/engines/oracle.py`, `describe_table` in `sql/engines/pgsql.py`which concatenates input which is passed to execution on the database in the `query` methods in `sql/engines/pgsql.py`, `describe_table` in `sql/engines/phoenix.py` which concatenates input which is passed to execution on the database in the `query` method in `sql/engines/phoenix.py`. Each of these issues may be mitigated by escaping user input or by using prepared statements when executing SQL queries. This issue is also indexed as `GHSL-2022-101`.
|
| Discourse is an open source platform for community discussion. In affected versions a user logged as an administrator can call arbitrary methods on the `SiteSetting` class, notably `#clear_cache!` and `#notify_changed!`, which when done on a multisite instance, can affect the entire cluster resulting in a denial of service. Users not running in multisite environments are not affected. This issue is patched in the latest stable, beta and tests-passed versions of Discourse. Users are advised to upgrade. There are no known workarounds for this vulnerability. |
