#vulnerability

Versions of nzo/url-encryptor-bundle prior to 5.0.1 and 4.3.2 are affected by a security vulnerability related to the lack of mandatory key and IV requirements. By default, the bundle uses the aes-256-ctr algorithm, which is susceptible to malleability attacks, potentially leading to Insecure Direct Object Reference (IDOR) vulnerabilities. Additionally, the reuse of keys enables users to decrypt and modify encrypted data if they can guess the plaintext of one ciphertext.

A remote code execution vulnerability has been found in the Swift Mailer library (swiftmailer/swiftmailer) recently. [See this advisory for details](http://legalhackers.com/advisories/SwiftMailer-Exploit-Remote-Code-Exec-CVE-2016-10074-Vuln.html). If you are not using the default mail() transport, this particular problem does not affect you. Upgrading is of course still recommended!

It has been discovered that Neos is vulnerable to several XSS attacks. Through these vulnerabilities, an attacker could tamper with page rendering, redirect victims to a fake login page, or capture user credentials (such as cookies). With the potential backdoor upload an attacker could gain access to the server itself, to an extent mainly limited by the server setup. ### Reflected Cross-Site Scripting (SXSS) with authentication A Neos backend user with permission to modify content can insert JavaScript instructions into content elements. The browser will execute the script in "Print" preview mode. A Neos backend user who can modify his profile information ("Title", "First Name", "Last name", "Middle Name", "Other Name") can inject JavaScript instructions in those parameters. Once set up, an administrator who wants to edit this user account will execute the code. Both attack vectors require a valid Neos backend user account. ### Reflected Cross-Site Scripting (RXSS) without authentica...

It has been discovered that TYPO3 Neos is vulnerable to Privilege Escalation. Logged in editors could access, create and modify content nodes that exist in the workspace of other editors.

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.

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