Vulnerabilities

Horilla is a free and open source Human Resource Management System (HRMS). In version 1.4.0, the has_xss() function attempts to block XSS by matching input against a set of regex patterns. However, the regexes are incomplete and context-agnostic, making them easy to bypass. Attackers are able to redirect users to malicious domains, run external JavaScript, and steal CSRF tokens that can be used to craft CSRF attacks against admins. This issue has been fixed in version 1.5.0.

Horilla is a free and open source Human Resource Management System (HRMS). Versions 1.4.0 and above expose unpublished job postings through the /recruitment/recruitment-details// endpoint without authentication. The response includes draft job titles, descriptions and application link allowing unauthenticated users to view unpublished roles and access the application workflow for unpublished jobs. Unauthorized access to unpublished job posts can leak sensitive internal hiring information and cause confusion among candidates. This issue has been fixed in version 1.5.0.

Horilla is a free and open source Human Resource Management System (HRMS). An Improper Access Control vulnerability exists in Horilla HR Software starting in version 1.4.0 and prior to version 1.5.0, allowing any authenticated employee to upload documents on behalf of another employee without proper authorization. This occurs due to insufficient server-side validation of the employee_id parameter during file upload operations, allowing any authenticated employee to upload document in behalf of any employee. Version 1.5.0 fixes the issue.

Horilla is a free and open source Human Resource Management System (HRMS). In versions prior to 1.5.0, a cross-site scripting vulnerability can be triggered because the extension and content-type are not checked during the profile photo update step. Version 1.5.0 fixes the issue.

Horilla is a free and open source Human Resource Management System (HRMS). A critical File Upload vulnerability in versions prior to 1.5.0, with Social Engineering, allows authenticated users to deploy phishing attacks. By uploading a malicious HTML file disguised as a profile picture, an attacker can create a convincing login page replica that steals user credentials. When a victim visits the uploaded file URL, they see an authentic-looking "Session Expired" message prompting them to re-authenticate. All entered credentials are captured and sent to the attacker's server, enabling Account Takeover. Version 1.5.0 patches the issue.

sm-crypto provides JavaScript implementations of the Chinese cryptographic algorithms SM2, SM3, and SM4. A private key recovery vulnerability exists in the SM2 decryption logic of sm-crypto prior to version 0.3.14. By interacting with the SM2 decryption interface multiple times, an attacker can fully recover the private key within approximately several hundred interactions. Version 0.3.14 patches the issue.

sm-crypto provides JavaScript implementations of the Chinese cryptographic algorithms SM2, SM3, and SM4. A signature malleability vulnerability exists in the SM2 signature verification logic of the sm-crypto library prior to version 0.3.14. An attacker can derive a new valid signature for a previously signed message from an existing signature. Version 0.3.14 patches the issue.

Seroval facilitates JS value stringification, including complex structures beyond JSON.stringify capabilities. In versions 1.4.0<br /> and below, serialization of objects with extreme depth can exceed the maximum call stack limit. In version 1.4.1, Seroval introduces a `depthLimit` parameter in serialization/deserialization methods. An error will be thrown if the depth limit is reached.

jsdiff is a JavaScript text differencing implementation. Prior to versions 8.0.3, 5.2.2, 4.0.4, and 3.5.1, attempting to parse a patch whose filename headers contain the line break characters `\r`, `\u2028`, or `\u2029` can cause the `parsePatch` method to enter an infinite loop. It then consumes memory without limit until the process crashes due to running out of memory. Applications are therefore likely to be vulnerable to a denial-of-service attack if they call `parsePatch` with a user-provided patch as input. A large payload is not needed to trigger the vulnerability, so size limits on user input do not provide any protection. Furthermore, some applications may be vulnerable even when calling `parsePatch` on a patch generated by the application itself if the user is nonetheless able to control the filename headers (e.g. by directly providing the filenames of the files to be diffed). The `applyPatch` method is similarly affected if (and only if) called with a string representation of a patch as an argument, since under the hood it parses that string using `parsePatch`. Other methods of the library are unaffected. Finally, a second and lesser interdependent bug - a ReDOS - also exhibits when those same line break characters are present in a patch&amp;#39;s *patch* header (also known as its "leading garbage"). A maliciously-crafted patch header of length *n* can take `parsePatch` O(*n*³) time to parse. Versions 8.0.3, 5.2.2, 4.0.4, and 3.5.1 contain a fix. As a workaround, do not attempt to parse patches that contain any of these characters: `\r`, `\u2028`, or `\u2029`.

go-tuf is a Go implementation of The Update Framework (TUF). Starting in version 2.0.0 and prior to version 2.3.1, a compromised or misconfigured TUF repository can have the configured value of signature thresholds set to 0, which effectively disables signature verification. This can lead to unauthorized modification to TUF metadata files is possible at rest, or during transit as no integrity checks are made. Version 2.3.1 fixes the issue. As a workaround, always make sure that the TUF metadata roles are configured with a threshold of at least 1.

go-tuf is a Go implementation of The Update Framework (TUF). Starting in version 2.0.0 and prior to version 2.3.1, if the TUF repository (or any of its mirrors) returns invalid TUF metadata JSON (valid JSON but not well formed TUF metadata), the client will panic during parsing, causing a denial of service. The panic happens before any signature is validated. This means that a compromised repository/mirror/cache can DoS clients without having access to any signing key. Version 2.3.1 fixes the issue. No known workarounds are available.

Grist is spreadsheet software using Python as its formula language. Grist offers several methods for running those formulas in a sandbox, for cases where the user may be working with untrusted spreadsheets. One such method runs them in pyodide, but pyodide on node does not have a useful sandbox barrier. If a user of Grist sets `GRIST_SANDBOX_FLAVOR` to `pyodide` and opens a malicious document, that document could run arbitrary processes on the server hosting Grist. The problem has been addressed in Grist version 1.7.9 and up, by running pyodide under deno. As a workaround, a user can use the gvisor-based sandbox by setting `GRIST_SANDBOX_FLAVOR` to `gvisor`.