Can you explain this vulnerability to me?

CVE-2026-38532 is a Broken Object-Level Authorization (BOLA) vulnerability in Webkul Krayin CRM version 2.2.x. It exists in the /Contact/Persons/PersonController.php endpoint, where the system fails to verify whether an authenticated user owns the contact record they are trying to access or modify.

Because of this flaw, an authenticated attacker with low privileges can craft GET, PUT, or DELETE HTTP requests with arbitrary person IDs to read, modify, or permanently delete any contact owned by other users.

• Affected endpoints include viewing, editing, updating, and deleting contacts via specific URLs such as GET /admin/contacts/persons/view/{id} and DELETE /admin/contacts/persons/{id}.

The root cause is missing authorization checks to confirm that the authenticated user has rights to the requested contact, making it possible to access or manipulate contacts belonging to others.

Useful 0 Not Useful 0

How can this vulnerability impact me? :

This vulnerability can have serious impacts including unauthorized access to sensitive contact information such as personal details, phone numbers, emails, and organizational affiliations.

Attackers can also modify or permanently delete contact records they do not own, leading to data integrity issues.

While it does not affect system availability, the confidentiality and integrity impacts are high, potentially resulting in customer data leakage, unauthorized data manipulation, and loss of competitive intelligence.

Useful 0 Not Useful 0

How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

The vulnerability poses a risk of customer data leakage and unauthorized access to personal information, which can lead to violations of privacy regulations such as GDPR.

Because attackers can read, modify, or delete sensitive contact data without proper authorization, organizations using the affected software may fail to comply with data protection standards that require strict access controls and data integrity safeguards.

Useful 0 Not Useful 0

How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by monitoring and testing the affected endpoints for unauthorized access to contact records by authenticated users with low privileges.

Specifically, crafted HTTP requests substituting arbitrary person IDs in the following endpoints can reveal the vulnerability:

• GET /admin/contacts/persons/view/{id} — to view person details
• GET /admin/contacts/persons/edit/{id} — to access the edit person form
• PUT /admin/contacts/persons/edit/{id} — to update person data
• DELETE /admin/contacts/persons/{id} — to delete a contact

To detect exploitation attempts on your network, you can use tools like curl or HTTP clients to send these crafted requests with different person IDs and observe if unauthorized data is accessible or modifiable.

Example curl commands to test unauthorized access (replace {id} with IDs not owned by the authenticated user):

• curl -i -X GET -H "Authorization: Bearer <token>" https://<your-domain>/admin/contacts/persons/view/{id}
• curl -i -X GET -H "Authorization: Bearer <token>" https://<your-domain>/admin/contacts/persons/edit/{id}
• curl -i -X PUT -H "Authorization: Bearer <token>" -d '{"field":"value"}' https://<your-domain>/admin/contacts/persons/edit/{id}
• curl -i -X DELETE -H "Authorization: Bearer <token>" https://<your-domain>/admin/contacts/persons/{id}

Monitoring audit logs for cross-user contact access attempts can also help detect exploitation.

Useful 0 Not Useful 0

What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation steps include implementing proper object-level authorization checks to ensure that authenticated users can only access, modify, or delete contacts they own.

• Verify ownership by checking that the person object's user_id matches the authenticated user's ID before processing GET, PUT, or DELETE requests.
• Implement Laravel Policy classes such as a PersonPolicy with view(), update(), and delete() methods enforcing ownership rules.
• Due to the systemic nature of the issue, create a shared ResourceOwnershipPolicy inherited by all resource controllers managing contacts, leads, activities, and users.
• Enable audit logging for all cross-user contact access attempts to detect and respond to unauthorized activities.

Since the fixed version is not publicly disclosed, applying these authorization checks and monitoring access is critical to mitigate the risk.

Useful 0 Not Useful 0