Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The PersistedUsernamePasswordProvider was prone to a information disclosure of account existance based on timing attacks as the hashing of passwords was only done in case an account was found. We changed the core so that the provider always does a password comparison in case credentials were submitted at all.
Recommended action: Upgrade to 3.3.5, 3.2.7, 3.1.7 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
3.2.134.0.63.1.103.3.133.0.12· Vendor fix available
Issue
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 (FlowPersistenceDoctrine)? 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…
Recommended action: Upgrade to 4.0.6, 3.3.13, 3.2.13 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
It has been discovered that Flow 3.0.0 allows arbitrary file uploads, inlcuding server-side scripts, posing the risk of attacks. If those scripts are executed by the server when accessed through their public URL, anything not blocked through other means is possible (information disclosure, placement of backdoors, data removal, …). Note: The upload of files is only possible if the application built on Flow provides means to do so, and whether or not the upload of files poses a risk is dependent on the system setup. If uploaded script files are not executed by the server, there is no risk. In versions prior to 3.0.0 the upload of files with the extension php was blocked. In Flow 2.3.0 to 2.3.6 a potential XML External Entity processing vulnerability has been discovered in the MediaTypeConverter.
Recommended action: Upgrade to 3.0.1 or 2.3.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Due to a missing signature (HMAC) for a request argument, an attacker could unserialize arbitrary objects within FLOW3. To our knowledge it is neither possible to inject code through this vulnerability, nor are there exploitable objects within the FLOW3 Base Distribution. However, there might be exploitable objects within user applications.
Recommended action: Upgrade to 1.0.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Cross-site scripting (XSS) vulnerability in the errorAction method in the ActionController base class in TYPO3 Flow (formerly FLOW3) 1.1.x before 1.1.1 and 2.0.x before 2.0.1 allows remote attackers to inject arbitrary web script or HTML via unspecified input, which is returned in an error message.
Recommended action: Upgrade to 2.0.1 or 1.1.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.