Latest News

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.

Due to reports it has been validated that internal workspaces in Neos are accessible without authentication. Some users assumed this is a planned feature but it is not. A workspace preview should be an additional feature with respective security measures in place. Note that this only allows reading of internal workspaces not writing. And for clarification, an internal workspace is a workspace that is non public and doesn't have an owner. Given that an internal workspace exists in your installation, it is possible to view a page in context of that workspace by opening a link in this format: https://domain/path/to/page.html@workspace-name The issue is quite problematic when exploited but at the same time slightly less impactful than it sounds. First of all there is no default internal workspace, so the issue affects only workspaces created by users. That also means the workspace-name, which will also always include a hash is individual to a project and an exploiter must get hold of t...

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 ...

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.

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.

Several widely-used JSON Web Token (JWT) libraries, including node-jsonwebtoken, pyjwt, namshi/jose, php-jwt, and jsjwt, are affected by critical vulnerabilities that could allow attackers to bypass the verification step when using asymmetric keys (RS256, RS384, RS512, ES256, ES384, ES512).

namshi/jose allows the acceptance of unsecure JSON Web Signatures (JWS) by default. The vulnerability arises from the $allowUnsecure flag, which, when set to true during the loading of JWSes, permits tokens signed with 'none' algorithms to be processed. This behavior poses a significant security risk as it could allow an attacker to impersonate users by crafting a valid jwt token.

By Deeba Ahmed North Korea targeted US companies with stolen identities in a cybercrime scheme. The Justice Department cracks down, seizes websites, and disrupts revenue streams. This is a post from HackRead.com Read the original post: Feds Bust N. Korean Identity Theft Ring Targeting US Firms

By Waqas Businesses today are highly concerned about preventing fraud in this age. As technology advances, so do activities, making… This is a post from HackRead.com Read the original post: How ID Scanning Apps Can Prevent Fraud

The cryptojacking group known as Kinsing has demonstrated its ability to continuously evolve and adapt, proving to be a persistent threat by swiftly integrating newly disclosed vulnerabilities to exploit arsenal and expand its botnet. The findings come from cloud security firm Aqua, which described the threat actor as actively orchestrating illicit cryptocurrency mining