ghsa

### Summary Still able to leak private fields if using the t(number) prefix ### Details Knex query allows you to change there default prefix ```SqliteError: select distinct `t0`.* from `pages` as `t0` left join `admin_users` as `t1` on `t0`.`updated_by_id` = `t1`.`id` where (`t1`.`password` = 1)``` so if you change the prefix to the same as it was before or to an other table you want to query you query changes from password to t1.password password is protected by filtering protections but t1.password is not protected ### PoC 1 Create a contentType 2 add to its options "populateCreatorFields" 3 create 1 entity in your new content type 4 in settings enable the find route in settings for the content type you created for public 5 /api/(Your contenttype)?filters%5BupdatedBy%5D%5Bt1.password%5D%5B%24startsWith%5D=a%24 And now the api returns noting if you were to do /api/(Your contenttype)?filters%5BupdatedBy%5D%5Bt1.password%5D%5B%24startsWith%5D=%24 it would return your entity ### Impa...

### Summary Anyone (Strapi developers, users, plugins) can make every attribute of a Content-Type public without knowing it. ### Details When dealing with content-types inside a Strapi instance, we can extend those using the appropriate container: ```javascript strapi.container.get('content-types').extend(contentTypeUID, (contentType) => newContentType); ``` The vulnerability only affects the handling of content types by Strapi, not the actual content types themselves. Users can use plugins or modify their own content types without realizing that the `privateAttributes` getter is being removed, which can result in any attribute becoming public. This can lead to sensitive information being exposed or the entire system being taken control of by an attacker(having access to password hashes). ### PoC Extend any content type on runtime (like in the bootstrap functions) and do a copy of the content-type object. ```javascript strapi.container.get('content-types').extend(contentTypeUID, (con...

Java object deserialization issue in Jackrabbit webapp/standalone on all platforms allows attacker to remotely execute code via RMIVersions up to (including) 2.20.10 (stable branch) and 2.21.17 (unstable branch) use the component "commons-beanutils", which contains a class that can be used for remote code execution over RMI. Users are advised to immediately update to versions 2.20.11 or 2.21.18. Note that earlier stable branches (1.0.x .. 2.18.x) have been EOLd already and do not receive updates anymore. In general, RMI support can expose vulnerabilities by the mere presence of an exploitable class on the classpath. Even if Jackrabbit itself does not contain any code known to be exploitable anymore, adding other components to your server can expose the same type of problem. We therefore recommend to disable RMI access altogether (see further below), and will discuss deprecating RMI support in future Jackrabbit releases. How to check whether RMI support is enabledRMI support can be o...

An uncontrolled resource consumption flaw was found in openstack-neutron. This flaw allows a remote authenticated user to query a list of security groups for an invalid project. This issue creates resources that are unconstrained by the user's quota. If a malicious user were to submit a significant number of requests, this could lead to a denial of service.

### Impact The module creates a system user that is used to perform internal module-to-module operations. Credentials for this user are hard-coded in the source code. This makes it trivial to authenticate as this user, allowing unauthorized read access to these mod-inventory-storage records: instances, holdings, items, contributor-types, identifier-types. This includes records marked as suppressed from discovery. ### Patches Upgrade mod-remote-storage to >=2.0.3, or a 1.7.x version >=1.7.1. ### Workarounds No known workarounds. ### References https://wiki.folio.org/x/hbMMBw - FOLIO Security Advisory with Upgrade Instructions https://github.com/folio-org/mod-remote-storage/commit/57df495f76e9aa5be9ce7ce3a65f89b6dbcbc13b - Fix

Certifi 2023.07.22 removes root certificates from "e-Tugra" from the root store. These are in the process of being removed from Mozilla's trust store. e-Tugra's root certificates are being removed pursuant to an investigation prompted by reporting of security issues in their systems. Conclusions of Mozilla's investigation can be found [here](https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/C-HrP1SEq1A).

### Impact Due to the use of the [object destructuring assignment](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment) syntax in the user export code path, combined with a path traversal vulnerability, a specially crafted payload could invoke the user export logic to arbitrarily execute javascript files on the local disk. ### Patches Patched in v2.8.7 ### Workarounds Site maintainers can cherry pick ec58700f6dff8e5b4af1544f6205ec362b593092 into their codebase to patch the exploit.

### Impact The module creates a system user that is used to perform internal module-to-module operations. Credentials for this user are hard-coded in the source code. This makes it trivial to authenticate as this user, resulting in unauthorized access to potentially dangerous APIs, allowing to view and modify configuration including single-sign-on configuration, to read, add and modify user data, and to read and transfer fees/fines in a patron's account. ### Patches Upgrade mod-data-export-spring to >=2.0.2, or a 1.5.x version >=1.5.4. ### Workarounds No known workarounds. ### References https://wiki.folio.org/x/hbMMBw - FOLIO Security Advisory with Upgrade Instructions https://github.com/folio-org/mod-data-export-spring/commit/93aff4566bff59e30f4121b5a2bda5b0b508a446 - Fix

### Impact Fix https://github.com/apptainer/apptainer/pull/1523 included in Apptainer 1.2.0-rc.2 has introduced an ineffective privilege drop when requesting container network setup, therefore subsequent functions are called with root privileges. The attack surface is rather limited for users but an attacker could possibly craft a starter config to delete any directory on the host filesystems. Only affects setuid installations of Apptainer. ### Patches The security fix https://github.com/apptainer/apptainer/pull/1578 has been included in Apptainer 1.2.1 ### Workarounds There is no known workaround outside of upgrading to Apptainer 1.2.1

Improper Neutralization of Special Elements Used in an SQL Command ('SQL Injection') vulnerability in Apache Software Foundation Apache InLong.This issue affects Apache InLong: from 1.4.0 through 1.7.0.  In the toAuditCkSql method, the groupId, streamId, auditId, and dt are directly concatenated into the SQL query statement, which may lead to SQL injection attacks. Users are advised to upgrade to Apache InLong's 1.8.0 or cherry-pick [1] to solve it. [1] https://github.com/apache/inlong/pull/8198