CVE-2026-111717 in Arkon
Summary
by MITRE • 10/16/2026
Arkon through 0.9.2 contains a missing authorization vulnerability in list_skill_versions that allows authenticated employees to read other departments' skill version metadata by bypassing the can_access_skill check. Attackers holding the default skill:read permission can request GET /api/skills/{slug}/versions for another department's skill to obtain version numbers, hashes, storage paths and changelogs.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in Arkon versions through 0.9.2 represents a critical failure in access control mechanisms within the application's API layer, specifically affecting the list_skill_versions endpoint. This flaw is categorized as an Insecure Direct Object Reference (IDOR) or Broken Access Control issue, aligning with CWE-639 and MITRE ATT&CK technique T1078, which covers valid accounts being used to access resources without proper authorization checks. The core technical deficiency lies in the implementation of the can_access_skill check, which is either missing or incorrectly implemented for this specific endpoint. Consequently, the application fails to verify whether the authenticated user requesting skill version metadata has legitimate ownership or permission rights over the target department's skills.
In a properly secured system, an API endpoint handling resource retrieval must validate that the requester possesses explicit authorization relative to the specific instance of data being accessed. In Arkon, while authentication is enforced, ensuring the user is logged in, the subsequent authorization step fails to cross-reference the requesting user’s role and departmental affiliation against the metadata of the requested skill version. This oversight allows any authenticated employee possessing the default skill:read permission to enumerate and retrieve sensitive information about skills belonging to other departments. The vulnerability effectively bypasses logical access controls that are intended to maintain data isolation between different organizational units within the platform.
The operational impact of this vulnerability is significant, as it enables unauthorized disclosure of internal system metadata. Attackers can exploit the GET /api/skills/{slug}/versions endpoint by manipulating the slug parameter associated with a target department's skill. By doing so, they gain access to version numbers, cryptographic hashes, storage paths, and detailed changelogs. The exposure of storage paths is particularly concerning as it may reveal internal infrastructure details or file system structures that could aid in further attacks such as path traversal or direct object reference exploitation against backend storage systems. Additionally, the disclosure of version numbers and hashes can assist attackers in identifying specific software versions to target known vulnerabilities associated with those releases, while changelogs might expose planned features or recent fixes that reveal internal development priorities and security patches applied by the organization.
Mitigation strategies must focus on implementing robust authorization checks at the API level. Developers should ensure that every endpoint performing data retrieval validates the relationship between the authenticated user’s identity and the resource being accessed. This involves verifying that the requesting user belongs to the same department as the skill or holds a higher-level administrative role with explicit permission to view cross-departmental resources. Input validation alone is insufficient; server-side authorization logic must be enforced for all API calls involving sensitive metadata. Furthermore, implementing principle of least privilege by restricting the default skill:read permission scope can limit the blast radius if such vulnerabilities are discovered in other parts of the application. Regular security audits and penetration testing focusing on access control flaws are recommended to identify similar gaps across the codebase before they can be exploited in production environments.