CVE-2026-38530
Received Received - Intake
Broken Object-Level Authorization in Webkul Krayin CRM Leads to Data Manipulation

Publication date: 2026-04-14

Last updated on: 2026-04-23

Assigner: MITRE

Description
A Broken Object-Level Authorization (BOLA) in the /Controllers/Lead/LeadController.php endpoint of Webkul Krayin CRM v2.2.x allows authenticated attackers to arbitrarily read, modify, and permanently delete any lead owned by other users via supplying a crafted GET request.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-04-14
Last Modified
2026-04-23
Generated
2026-05-07
AI Q&A
2026-04-14
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
webkul krayin_crm 2.2.0
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-639 The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2026-38530 is a Broken Object-Level Authorization (BOLA) vulnerability in Webkul Krayin CRM version 2.2.x. It exists in the lead management endpoint, specifically in the LeadController.php file. The vulnerability occurs because the system does not verify whether the authenticated user owns the lead object they are trying to access or modify.

Authenticated users can exploit this vulnerability by sending crafted GET, PUT, or DELETE requests with arbitrary lead IDs. This allows them to read, modify, or permanently delete leads owned by other users without proper authorization checks.

The root cause is the absence of an authorization check ensuring that the lead's user_id matches the authenticated user's ID. While the system verifies that the user is authenticated, it fails to enforce ownership validation or delegation permissions on lead objects.


How can this vulnerability impact me? :

This vulnerability can have significant impacts including unauthorized disclosure, modification, and deletion of sensitive lead data.

  • Confidentiality impact: Attackers can access sensitive lead information such as contact details, deal values, and sales pipeline data belonging to other users.
  • Integrity impact: Attackers can modify lead data, including unauthorized changes to deal statuses.
  • Destructive impact: Attackers can permanently delete leads owned by other users, causing loss of important sales records.

Although availability is not directly affected, the deletion of leads can disrupt business operations and cause competitive intelligence leakage.


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 lead management endpoints for unauthorized access to leads owned by other users. Specifically, you can attempt to send crafted GET, PUT, or DELETE requests to the following endpoints with arbitrary lead IDs to check if the system improperly allows access or modification:

  • GET /admin/leads/edit/{id}
  • PUT /admin/leads/edit/{id}
  • DELETE /admin/leads/{id}

If these requests succeed in accessing or modifying leads that do not belong to the authenticated user, the vulnerability is present. Detection can be done using tools like curl or HTTP clients to craft these requests while authenticated as a low-privilege user.

Example curl command to test GET access to another user's lead (replace {id} and authentication details accordingly):

  • curl -i -H "Cookie: session=your_auth_session" https://your-krayin-crm-domain/admin/leads/edit/{id}

Similarly, PUT and DELETE requests can be crafted to test modification and deletion capabilities.


What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves implementing strict object-level authorization checks in the lead management endpoints to ensure that the lead's user_id matches the authenticated user's ID or that the user has explicit sharing or delegation permissions.

Specifically, it is recommended to use Laravel Policy classes (LeadPolicy) with methods such as view(), update(), and delete() to enforce ownership rules before processing any lead-related requests.

Additionally, audit logging should be enabled to record all attempts to access leads owned by other users, which helps in monitoring and detecting exploitation attempts.

Until a fixed version is available, restrict access to the lead management endpoints to trusted users and consider applying temporary access controls or monitoring to detect suspicious activity.


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

This vulnerability allows authenticated attackers to arbitrarily read, modify, and delete lead data owned by other users, resulting in unauthorized disclosure and alteration of sensitive information such as contact details and sales data.

Such unauthorized access and modification of personal and business data can lead to violations of data protection regulations like GDPR and HIPAA, which require strict controls on data confidentiality, integrity, and access authorization.

Specifically, the high confidentiality and integrity risks posed by this Broken Object-Level Authorization (BOLA) vulnerability could result in non-compliance with requirements for protecting personal data from unauthorized access and ensuring data accuracy.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart