CVE-2026-70561

TestLink 1.9.50 and later contain an IDOR in the attachment download handler (attachmentdownload.php) that allows any authenticated user—including low-privilege guest accounts—to download attachments from any project by simply incrementing an integer ID in the request. The vulnerability works because TestLink checks project-level permissions only in the UI layer (when rendering navigation and filtering sidebar menus) but performs no equivalent authorization check when the download endpoint is called directly with a numeric attachment ID. This is not a forgotten check; it's a missing one. The developers who built the attachment retrieval handler never implemented an authorization gate because they assumed only authenticated users navigating through the application would reach it. Sequential integer IDs are the symptom of that assumption—secure systems use opaque identifiers (UUIDs, tokens, salted hashes) precisely to prevent enumeration, and the fact that TestLink uses incrementing integers tells you the data retrieval layer was built on a different trust model than the presentation layer. The guest account vector makes this worse. Guest accounts in TestLink are typically low-privilege users who should only see projects they're explicitly granted access to. Instead, they can enumerate attachments across every project in the installation, harvesting test specifications, requirements documents, execution evidence, and any sensitive data employees have uploaded. In regulated industries, this is not just a confidentiality breach—it creates potential compliance violations, audit failures, and disclosure obligations. The CVSS 6.5 score badly understates this risk. What to do now: First, patch immediately—TestLink has released fixes for this in recent versions. Second, audit your guest accounts and consider whether unauthenticated or low-privilege access should be restricted to specific projects rather than granted installation-wide. Third, assume that attachments uploaded before the patch may have been enumerated—review what sensitive documents exist in your TestLink instance and treat any that contain credentials, architecture diagrams, integration tokens, or strategic planning as potentially compromised. Fourth, scan your TestLink instance for other endpoints that accept numeric IDs and may lack similar authorization checks—this vulnerability class has appeared in TestLink attachment handlers before, and a per-endpoint patch doesn't fix the underlying architectural pattern. Finally, review your patch deployment timeline: the exposure window existed for years before disclosure, and organizations that delay updates remain vulnerable to adversaries who may have already harvested your document history.

Reviewed through automated stages and approved by a human before publication.