CVE-2026-18818
A weakness has been identified in Ehco1996 django-sspanel up to 2023.12.26. This affects the function TicketDetailView of the file apps/sspa
CVSS
6.3
Medio
EPSS
—
KEV
—
Exploit Today
0
0-100
Publicado: 4 ago 2026 · Última mod.: 4 ago 2026 · CWE-285 · CWE-639
Sin historial EPSS suficiente todavía.
A weakness has been identified in Ehco1996 django-sspanel up to 2023.12.26. This affects the function TicketDetailView of the file apps/sspanel/views.py of the component Support Ticket Handler. Executing a manipulation can lead to authorization bypass. The attack can be executed remotely. The vendor was contacted early about this disclosure but did not respond in any way. This vulnerability only affects products that are no longer supported by the maintainer.
CVECVSSEPSSKEVRExplotTítuloVis.
CVE-2026-48912——
———Improper Input Validation vulnerability in Apache Answer.
This issue affects Apache Answer: through 2.0.1.
A missing ownership check in the avatar-cleanup logic allows any authenticated user to delete other users' uploaded files by supplying their file URLs.
Users are recommended to upgrade to version 2.0.2, which fixes the issue.5hCVE-2026-712516.5 MED—
——0Akaunting's shared download route (app/Http/Controllers/Common/Uploads.php::download(), reachable at uploads/{id}/download behind only generic auth middleware) fetched the requested Media record by ID with no verification that it belonged to the requesting portal customer's own company, allowing any authenticated portal customer to download any other company's uploaded files by guessing or enumerating media IDs. Fixed in commit 80ef6d3 (2026-07-12), which added an explicit ownership check comparing the media's parent record contact_id against the requesting user's own contact.9hCVE-2026-712428.3 ALT—
——0Crater'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->company_id). 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).9hCVE-2026-557398.3 ALT—
——0Crater isolates data per company_id, and its Invoice/Estimate/Payment/Expense policies enforce both a Bouncer ability check and $user->hasCompany($model->company_id). CustomerPolicy's view/update/delete methods omit the company-ownership check entirely, checking only the blanket ability. Route-model-bound customer lookups and the bulk Customer::deleteCustomers() method are similarly unscoped (self::find($id) with no company filter). Any authenticated user of one company can read, reassign (steal), or delete another company's customer records, with deletion cascading to that customer's invoices and payments.8hCVE-2026-114546.5 MED—
——0The Groundhogg — CRM, Newsletters, and Marketing Automation plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 4.5.2 via the GET /wp-json/gh/v4/contacts/<id> REST endpoint. The endpoint's permission callback checks only the role-level view_contacts capability and read_single() returns the full contact record by sequential integer ID without the object-level view_contact ownership check applied elsewhere in the codebase. This makes it possible for authenticated attackers holding view_contacts but not view_others_contacts — notably Groundhogg's built-in Sales Rep role, designed to see only its own contacts — to read any contact record on the site, including PII, contact meta, owner IDs, the admin edit URL, and (for contacts linked to a WordPress user) that user's full capability set.8hCVE-2026-188172.2 BAJ—
——0A security flaw has been discovered in Baserow up to 2.3.2. Affected by this issue is the function BaserowImpersonateAuthTokenSerializer of the file backend/src/baserow/api/admin/users/serializers.py of the component Inactive Non-Staff User Handler. Performing a manipulation results in improper authorization. Remote exploitation of the attack is possible. The complexity of an attack is rather high. The exploitation is known to be difficult. The presence of this vulnerability remains uncertain at this time. Upgrading to version 2.3.3 can resolve this issue. The affected component should be upgraded. The project maintainer explains: "While the problem exists, I'm not really sure if it's a vulnerability. (....) Even though the back gives a token for a deactivate user, none of the endpoints actually work. That said, we will fix it, but so far it seems more like a bug instead of a vulnerability."6h