ghsa

php-censor v2.1.4 and fixed in v.2.1.5 was discovered to utilize a weak hashing algorithm for its remember_key value. This allows attackers to bruteforce to bruteforce the remember_key value to gain access to accounts that have checked "remember me" when logging in.

Konga v0.14.9 is vulnerable to Cross Site Scripting (XSS) via the username parameter.

An issue was discovered in Bouncy Castle Java Cryptography APIs before 1.78. An Ed25519 verification code infinite loop can occur via a crafted signature and public key.

An issue was discovered in Bouncy Castle Java TLS API and JSSE Provider before 1.78. Timing-based leakage may occur in RSA based handshakes because of exception processing.

An issue was discovered in ECCurve.java and ECCurve.cs in Bouncy Castle Java (BC Java) before 1.78, BC Java LTS before 2.73.6, BC-FJA before 1.0.2.5, and BC C# .Net before 2.3.1. Importing an EC certificate with crafted F2m parameters can lead to excessive CPU consumption during the evaluation of the curve parameters.

### Summary Currently session tokens function like the other JWT tokens where they are not actually invalidated when logging out. The `directus_session` gets destroyed and the cookie gets deleted but if you captured the cookie value it will still work for the entire expiry time which is set to 1 day by default. Making it effectively a long lived unrevokable stateless token instead of the stateful session token it was meant to be. When authenticating a session token JWT, Directus should also check whether the associated `directus_session` both still exists and has not expired (although the token should expire at the same time or before the session) to ensure leaked tokens are not valid indefinitely. ## Steps to reproduce - Copy the current session token from the cookie - Refresh and or log out - Use the saved session token to check if it is still valid ### Impact The lack of proper session expiration may improve the likely success of certain attacks. For example, a user might access a...

### Impact A Nautobot user with admin privileges can modify the `BANNER_TOP`, `BANNER_BOTTOM`, and `BANNER_LOGIN` configuration settings via the `/admin/constance/config/` endpoint. Normally these settings are used to provide custom banner text at the top and bottom of all Nautobot web pages (or specifically on the login page in the case of `BANNER_LOGIN`) but it was reported that an admin user can make use of these settings to inject arbitrary HTML, potentially exposing Nautobot users to security issues such as cross-site scripting (stored XSS). ### Patches _Has the problem been patched? What versions should users upgrade to?_ Patches will be released as part of Nautobot 1.6.22 and 2.2.4. ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ As [described in the Nautobot documentation](https://docs.nautobot.com/projects/core/en/stable/user-guide/administration/configuration/optional-settings/#administratively-configurable-settings), t...

### Summary A stored cross-site scripting vulnerability exists within the Formula virtual cell comments functionality. ### Details The nc-gui/components/virtual-cell/Formula.vue displays a v-html tag with the value of "urls" whose contents are processed by the function replaceUrlsWithLink(). This function recognizes the pattern URI::(XXX) and creates a hyperlink tag <a> with href=XXX. However, it leaves all the other contents outside of the pattern URI::(XXX) unchanged, which makes the evil users can create a malicious table with a formula field whose payload is <img src=1 onerror="malicious javascripts"URI::(XXX). The evil users then can share this table with others by enabling public viewing and the victims who open the shared link can be attacked. ### PoC Step 1: Attacker login the nocodb and creates a table with two fields, "T" and "F". The type of field "T" is "SingleLineText", and the type of the "F" is "Fomula" with the formula content {T} Step 2: The attacker sets the content...

## Summary A user with permission to view any collection using redacted hashed fields can get access the raw stored version using the `alias` functionality on the API. Normally, these redacted fields will return `**********` however if we change the request to `?alias[workaround]=redacted` we can instead retrieve the plain text value for the field. ## Steps to reproduce - Set up a simple role with read-access to users. - Create a new user with the role from the previous step - Assign a password to the user The easiest way to confirm this vulnerability is by first visiting `/users/me`. You should be presented with a redacted JSON-object. Next, visit `/users/me?alias[hash]=password`. This time, the returned JSON object will included the raw password hash instead of the redacted value. ## Workaround This can be avoided by removing permission to view the sensitive fields entirely from users or roles that should not be able to see them.

### Summary --- An authenticated attacker with create access could conduct a SQL Injection attack on MySQL DB using unescaped table_name. ### Details --- ### SQL Injection vulnerability occurs in **VitessClient.ts**. ```javascript async columnList(args: any = {}) { const func = this.columnList.name; const result = new Result(); log.api(`${func}:args:`, args); try { args.databaseName = this.connectionConfig.connection.database; const response = await this.sqlClient.raw( `select *, table_name as tn from information_schema.columns where table_name = '${args.tn}' ORDER by ordinal_position`, ); ``` The variable **${args.tn}** refers to the table name entered by the user. A malicious attacker can escape the existing query by including a special character (') in the table name and insert and execute a new arbitrary SQL query. ### Impact --- This vulnerability may result in leakage of sensitive data in the database.