Security
Headlines
HeadlinesLatestCVEs

Source

ghsa

GHSA-7vr7-cghh-ch63: XWiki Platform may retrieve email addresses of all users

### Impact The mail obfuscation configuration was not fully taken into account and while the mail displayed to the end user was obfuscated: - the rest response was also containing the mail unobfuscated - user were able to filter and sort on the unobfuscated (allowing to infer the mail content) The consequence was the possibility to retrieve the email addresses of all users even when obfuscated. See https://jira.xwiki.org/browse/XWIKI-20333 for the reproduction steps. ### Patches This has been patched in XWiki 14.10.4, XWiki 14.4.8, and XWiki 15.0-rc-1. ### Workarounds The workaround is to modify the page `XWiki.LiveTableResultsMacros` following this [patch](https://github.com/xwiki/xwiki-platform/commit/71f889db9962df2d385f4298e29cfbc9050b828a#diff-5a739e5865b1f1ad9d79b724791be51b0095a0170cc078911c940478b13b949a). ### References https://jira.xwiki.org/browse/XWIKI-20333 ### For more information If you have any questions or comments about this advisory: * Open an issue in [J...

ghsa
#vulnerability#mac#git#java#jira#maven
GHSA-7f2f-pcv3-j2r7: XWiki Platform's tags on non-viewable pages can be revealed to users

### Impact Tags from pages not viewable to the current user are leaked by the tags API. This information can also be exploited to infer the document reference of non-viewable pages. ### Patches This vulnerability has been patched in XWiki 14.4.8, 14.10.4, and 15.0 RC1. ### Workarounds There is no workaround apart from upgrading to a fixed version. ### References - https://jira.xwiki.org/browse/XWIKI-20002 ### 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:[email protected])

GHSA-g75c-cjr6-39mc: XWiki Platform's Mail.MailConfig can be edited by any user with edit rights

### Impact `Mail.MailConfig` can be edited by any logged-in user by default. Consequently, they can: - change the mail obfuscation configuration - view and edit the mail sending configuration, including the smtp domain name and credentials. ### Patches The problem has been patched on XWiki 14.4.8, 15.1, and 14.10.6. ### Workarounds The rights of the `Mail.MailConfig` page can be manually updated so that only a set of trusted users can view, edit and delete it (e.g., the `XWiki.XWikiAdminGroup` group). On 14.4.8+, 15.1-rc-1+, or 14.10.5+, if at startup `Mail.MailConfig` does not have any rights defined, `view`, `edit ` and `delete` rights are automatically granted to the `XWiki.XWikiAdminGroup` group. See the corresponding [patch](https://github.com/xwiki/xwiki-platform/commit/d28d7739089e1ae8961257d9da7135d1a01cb7d4). ### References - https://jira.xwiki.org/browse/XWIKI-20519 + https://jira.xwiki.org/browse/XWIKI-20671 - https://github.com/xwiki/xwiki-platform/commit/d28d7739089e1a...

GHSA-fp7h-f9f5-x4q7: XWiki vulnerable to stored cross-site scripting via any wiki document and the displaycontent/rendercontent template

### Impact Any user who can edit a document in a wiki like the user profile can create a stored XSS attack by putting plain HTML code into that document and then tricking another user to visit that document with the `displaycontent` or `rendercontent` template and plain output syntax. For example, edit any document with the wiki editor and set the content to `<script>alert(1)</script>` , save and then append the parameters `?viewer=displaycontent&sheet=&outputSyntax=plain`. If this displays an alert, the installation is vulnerable. If a user with programming rights is tricked into visiting such a URL, arbitrary actions be performed with this user's rights, impacting the confidentiality, integrity, and availability of the whole XWiki installation. ### Patches This has been patched in XWiki 14.4.8, 14.10.5 and 15.1RC1 by setting the content type of the response to plain text when the output syntax is not an HTML syntax. ### Workarounds The [patch](https://github.com/xwiki/xwiki-platfo...

GHSA-8rc9-vxjh-qjf2: Vega's validators able to submit duplicate transactions

A vulnerability exists that allows a malicious validator to trick the Vega network into re-processing past Ethereum events from Vega’s Ethereum bridge. For example, a deposit to the collateral bridge for 100USDT that credits a party’s general account on Vega, can be re-processed 50 times resulting in 5000USDT in that party’s general account. This is without depositing any more than the original 100USDT on the bridge. Despite this exploit requiring access to a validator's Vega key, a validator key can be obtained at the small cost of 3000VEGA, the amount needed to announce a new node onto the network. The steps to carry out this exploit are as follows: 1. Cause an Ethereum event on one of the bridge contracts e.g a deposit to the collateral bridge, or the staking bridge 2. This will result in the Ethereum-event-forwarder of each node to submit a ChainEvent transaction to the Vega network corresponding to that event 3. Scrape the valid chain event transaction from the Tendermint block ...

GHSA-6mjq-h674-j845: netty-handler SniHandler 16MB allocation

### Summary The `SniHandler` can allocate up to 16MB of heap for each channel during the TLS handshake. When the handler or the channel does not have an idle timeout, it can be used to make a TCP server using the `SniHandler` to allocate 16MB of heap. ### Details The `SniHandler` class is a handler that waits for the TLS handshake to configure a `SslHandler` according to the indicated server name by the `ClientHello` record. For this matter it allocates a `ByteBuf` using the value defined in the `ClientHello` record. Normally the value of the packet should be smaller than the handshake packet but there are not checks done here and the way the code is written, it is possible to craft a packet that makes the `SslClientHelloHandler` 1/ allocate a 16MB `ByteBuf` 2/ not fail `decode` method `in` buffer 3/ get out of the loop without an exception The combination of this without the use of a timeout makes easy to connect to a TCP server and allocate 16MB of heap memory per connection. ...

GHSA-298m-hvgh-x9cw: Alluxio Cross Site Scripting vulnerability

Cross Site Scripting vulnerability in Alluxio v.1.8.1 allows a remote attacker to executea arbitrary code via the path parameter in the browse board component.

GHSA-6643-h7h5-x9wh: Langchain vulnerable to arbitrary code execution

Langchain 0.0.171 is vulnerable to Arbitrary code execution in `load_prompt`.

GHSA-6vf2-mfmr-qqqw: Liufee CMS File Upload vulnerability

File Upload vulnerability in Liufee CMS, AKA Feehicms v.2.0.8 allows a remote attacker to execute arbitrary code via the `/admin/index.php?r=admin-user%2Fupdate-self` component.

GHSA-4cw3-rhqx-vqwr: GilaCMS Cross Site Request Forgery vulnerability

Cross Site Request Forgery vulnerability in Gila GilaCMS v.1.11.4 allows a remote attacker to execute arbitrary code via the `cm/update_rows/user` parameter.