User-controlled key authorization bypass in Cozmoslabs User Profile Picture

Authorization Bypass Through User-Controlled Key vulnerability in Cozmoslabs User Profile Picture metronet-profile-picture allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects User Profile Picture: from n/a through <= 2.6.3.

• Cozmoslabs User Profile Picture, package metronet-profile-picture: the affected version entry starts at 0 and is affected through 2.6.3, with versionType set to custom.
• The affected record sets default_status to unaffected outside the stated affected range.
• The status change identifies 2.6.4 as unaffected. The status of parallel branches or other releases should not be inferred without separate supporting evidence.

The weakness is CWE-639, Authorization Bypass Through User-Controlled Key, and Patchstack describes it as an Insecure Direct Object Reference (IDOR). The affected component is the metronet-profile-picture package. In this class of flaw, an attacker can provide or alter a key used to identify an object or resource while the authorization layer fails to fully verify access to that object. This is a class-level explanation based on the CWE and IDOR classification. The available evidence does not identify the key name, request route, affected object type, or implementation code path. The attack is network reachable, has low complexity, requires high privileges, and does not require user interaction. The supplied assessment records the scope as unchanged.

The vulnerability is reachable over the network and requires an attacker to hold high privileges in the application. The assessed attack complexity is low and no interaction from another user is required. The supplied record marks public_exploit as false and does not identify a campaign, victim, or specific exploit. The returned CISA-ADP assessment records exploitation as none and automatable as no. That is a bounded assessment of the available record and does not prove that abuse is impossible.

Successful exploitation could bypass object-level authorization and cause unauthorized integrity changes to data managed by the plugin. The available assessment indicates no confidentiality or availability impact and records an unchanged scope. Because the affected object and operation are not disclosed, it is not possible to conclude that profile images, account records, or any other specific data type will be changed. The organizational consequence depends on the privileges of the abused account and the functionality exposed to that account.

• A user who already holds the required high-level privileges may bypass intended access controls and make unauthorized changes to plugin-managed data.
• The supplied assessment identifies limited integrity impact and does not identify confidentiality or availability impact.
• Actual business exposure depends on the object protected by the vulnerable code path and the set of privileged users who can reach that functionality.
• The available evidence does not confirm a breach, victim, campaign, or specific data loss.

1. Update metronet-profile-picture to 2.6.4, the release identified as unaffected in the affected data.
2. After updating, verify that the WordPress site inventory reports the corrected package and version, then review the related profile picture functions.
3. If updating is not immediately possible, consult the plugin maintainer, hosting provider, or web developer for a supported mitigation. The available evidence does not document a specific workaround.
4. Prioritize sites where high-privilege accounts can use the plugin, and do not treat the absence of suspicious log entries as proof that exposure has been removed.

• Check WordPress site inventories for the metronet-profile-picture package and confirm whether the plugin is installed and enabled.
• Compare the installed package version with the affected and fixed boundaries in affected_summary.
• Identify high-privilege accounts that can access the plugin's functionality, because the assessment does not describe unauthenticated access.
• Review web or application logs for authenticated requests to plugin functionality that show unexpected changes to object or profile identifiers. Treat this as a precautionary review, not a confirmed IOC, because the specific key and endpoint have not been disclosed.
• Absence of suspicious log entries does not prove that a site is safe while the plugin remains within the affected boundary.