CVE-2026-71242: Crater: Cross-Company IDOR on Notes via Missing Company-Ownership Check in NotePolicy

Published Aug 5, 2026
·
Updated

Crater's NotePolicy checks only a blanket Bouncer ability (manage-all-notes / view-all-notes) with no company-ownership comparison, unlike InvoicePolicy and other sibling policies which additionally verify $user->hasCompany($model->companyid). NotesController's show(), update(), and destroy() actions authorize via $this->authorize('view notes'/'manage notes') without passing the target Note model, and Note's company-scoping (scopeWhereCompany) is applied only in the list endpoint, not in show/update/destroy. Any authenticated user of one company can read, edit, or delete another company's notes by ID. This is a distinct finding from the previously reported CustomerPolicy company-ownership omission (a different policy class and controller).

Affected Software

1 affected component
Crater

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Configuration

    Update NotesController actions (show, update, destroy) to authorize using the target Note model (e.g., call $this->authorize('view notes', $note) / $this->authorize('manage notes', $note)) rather than only using blanket abilities.

    Crater NotesController Authorization calls in show(), update(), destroy() = Pass target Note model to authorize() so policy can enforce company ownership
  2. Configuration

    Modify NotePolicy so it checks that the authenticated user owns the target Note (company_id match), similar to sibling policies that additionally verify $user->hasCompany($model->company_id); do not rely only on manage-all-notes/view-all-notes without company comparison.

    Crater NotePolicy Company ownership check for notes = Add per-note company-ownership verification in addition to blanket Bouncer abilities
  3. Configuration

    Ensure Note model company-scoping (scopeWhereCompany) is enforced for show(), update(), and destroy() note retrieval/queries, not only in the list endpoint.

    Crater Notes model / query scoping (scopeWhereCompany) Applying company scoping to single-note access = Apply scopeWhereCompany to show/update/destroy lookups as well as list endpoint

Event History

Aug 5, 2026
CVE Published
via MITRE·10:56 AM
Data Sourced
via MITRE·10:56 AM
DescriptionSeverityWeakness
Data Sourced
via NVD·11:16 AM
DescriptionSeverityWeakness
Dec 21, 58563
Event
via NVD·01:59 PM
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-71242?

CVE-2026-71242 has a severity rating of 8.2, which is classified as high.

2

How do I fix CVE-2026-71242?

To fix CVE-2026-71242, implement a company-ownership check within the NotePolicy to restrict access based on user ownership.

3

What types of actions are affected by CVE-2026-71242?

CVE-2026-71242 affects the show(), update(), and destroy() actions in the NotesController.

4

What is the risk associated with CVE-2026-71242?

CVE-2026-71242 carries a risk level of 68, indicating potential unauthorized access to sensitive notes.

5

Who is impacted by the CVE-2026-71242 vulnerability?

Organizations using Crater may be impacted by CVE-2026-71242, particularly those relying on NotePolicy for note management.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203