Security
Headlines
HeadlinesLatestCVEs

Headline

GHSA-9cw3-j7wg-jwj8: Neos Flow Information disclosure in entity security

If you had used entity security and wanted to secure entities not just based on the user’s role, but on some property of the user (like the company he belongs to), entity security did not work properly together with the doctrine query cache. This could lead to other users re-using SQL queries from the cache which were built for other users; and thus users could see entities which were not destined for them.

Am I affected?

  • Do you use Entity Security? if no, you are not affected.
  • You disabled the Doctrine Cache (Flow_Persistence_Doctrine)? If this is the case, you are not affected.
  • You use Entity Security in custom Flow or Neos applications. Read on.
    • If you only used Entity Security based on roles (i.e. role A was allowed to see entities, but role B was denied): In this case, you are not affected.
    • If you did more advanced stuff using Entity Security (like checking that a customer only sees his own orders; or a hotel only sees its own bookings), you very likely needed to register a custom global object in Neos.Flow.aop.globalObjects. In this case, you are affected by the issue; and need to implement the CacheAwareInterface in your global object for proper caching.

All Flow versions (starting in version 3.0, where Entity Security was introduced) were affected.

ghsa
#sql#git#php#perl
  1. GitHub Advisory Database
  2. GitHub Reviewed
  3. GHSA-9cw3-j7wg-jwj8

Neos Flow Information disclosure in entity security

Moderate severity GitHub Reviewed Published May 17, 2024 to the GitHub Advisory Database • Updated May 17, 2024

Package

Affected versions

>= 3.0.0, < 3.0.12

>= 3.1.0, < 3.1.10

>= 3.2.0, < 3.2.13

>= 3.3.0, < 3.3.13

>= 4.0.0, < 4.0.6

Patched versions

3.0.12

3.1.10

3.2.13

3.3.13

4.0.6

If you had used entity security and wanted to secure entities not just based on the user’s role, but on some property of the user (like the company he belongs to), entity security did not work properly together with the doctrine query cache. This could lead to other users re-using SQL queries from the cache which were built for other users; and thus users could see entities which were not destined for them.

Am I affected?

  • Do you use Entity Security? if no, you are not affected.
  • You disabled the Doctrine Cache (Flow_Persistence_Doctrine)? If this is the case, you are not affected.
  • You use Entity Security in custom Flow or Neos applications. Read on.
    • If you only used Entity Security based on roles (i.e. role A was allowed to see entities, but role B was denied): In this case, you are not affected.
    • If you did more advanced stuff using Entity Security (like checking that a customer only sees his own orders; or a hotel only sees its own bookings), you very likely needed to register a custom global object in Neos.Flow.aop.globalObjects. In this case, you are affected by the issue; and need to implement the CacheAwareInterface in your global object for proper caching.

All Flow versions (starting in version 3.0, where Entity Security was introduced) were affected.

References

  • https://github.com/FriendsOfPHP/security-advisories/blob/master/neos/flow/2017-04-12.yaml
  • https://www.neos.io/blog/flow-bugfix-releases-for-entity-security.html

Published to the GitHub Advisory Database

May 17, 2024

Last updated

May 17, 2024

ghsa: Latest News

GHSA-8gc2-vq6m-rwjw: Amazon Redshift Python Connector vulnerable to SQL Injection