Threats affecting pkg:github/ail-framework

AIL Framework versions before 7.0 contain a server-side request forgery (SSRF) vulnerability in the crawler submission feature. Authenticated users with low privileges can submit arbitrary URLs for crawling without sufficient validation, allowing requests to internal or restricted network addresses. This includes localhost, private IP ranges, link-local addresses, and cloud metadata services. The vulnerability enables attackers to use the server as a pivot to access internal services and retrieve sensitive data such as HTML content, screenshots, and HAR data. A patch has been introduced to validate and reject URLs resolving to non-global IP addresses, mitigating this risk.

AIL Project's ail-framework contains a stored cross-site scripting (XSS) vulnerability in the translation controls for chat messages and forum posts. The vulnerability arises because message and post identifiers are inserted directly into inline JavaScript onclick handlers without proper encoding for JavaScript string literals. This allows an attacker to inject arbitrary JavaScript code if a specially crafted identifier is used. Exploitation requires a victim to click the affected translation button, causing the injected script to execute in the victim's browser under the AIL instance's security context.

AIL Framework versions up to 7.0.0 contain a stored cross-site scripting (XSS) vulnerability in the crawler domain view. This flaw allows an attacker to inject malicious JavaScript into stored URLs that are later embedded unsafely into a JavaScript onclick handler. Exploitation requires an authenticated analyst to interact with the malicious screenshot entry, potentially enabling session information access or unauthorized actions within the application context. The vulnerability is due to improper input neutralization and was fixed by applying Jinja's tojson filter to safely escape the URL before insertion.

AIL Framework versions up to 7.0.0 contain a reflected cross-site scripting (XSS) vulnerability in the /tag/add_tags endpoint. The vulnerability occurs because error messages include attacker-controlled input directly in HTML responses without proper encoding. Exploitation requires an authenticated user to interact with a crafted link, potentially allowing execution of arbitrary JavaScript in the victim's browser within the application's security context. This could enable actions such as session hijacking or data modification based on the victim's privileges.

AIL Framework contains a path traversal vulnerability in its PDF object handling. Prior to commit 14c618fce4d1df02358717c48ea903706abecdf2, the PDF.get_filepath() function constructed a file path by joining the configured PDF storage directory with a path derived from a PDF object identifier, without verifying that the resolved path remained within the intended PDF_FOLDER directory. An authenticated attacker able to invoke PDF object operations with a crafted identifier could use relative traversal sequences or absolute path components to cause AIL Framework to open files located outside the PDF storage directory. This could allow disclosure of files readable by the AIL process, including application configuration, credentials, or other sensitive local data. This vulnerability is potential due to additional errors before being able to be executed. The fix canonicalises the resulting path with os.path.realpath() and rejects paths whose common directory is outside the configured PDF directory.

AIL framework contains a path traversal vulnerability in the /objects/item/diff endpoint. The endpoint accepts item identifiers through the s1 and s2 query parameters and, prior to the fix, attempted to retrieve and compare item contents without first verifying that both referenced items existed as valid AIL objects. An authenticated AIL user could craft malicious item identifiers containing path traversal sequences to cause the application to read gzip-compressed files accessible to the AIL process. This could result in unauthorized disclosure of local file contents, limited to files readable by the application and compatible with the expected gzip-compressed item format. The issue was fixed by validating that both requested items exist before their contents are accessed.