EUVD-2026-29500
GHSA-v7m4-rwp4-vmrq
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H
Primary rating from NVD · only source for this CVE.
CVSS VectorNVD
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H
Lifecycle Timeline
4DescriptionCVE.org
The nexent v1.7.5.2 backend service contains an unauthorized arbitrary storage file deletion vulnerability in its file management API. The DELETE /storage/{object_name:path} endpoint lacks authentication, authorization, and input validation mechanisms. Unauthenticated remote attackers can send crafted requests with a user-controlled object_name path parameter to delete arbitrary files from the underlying MinIO storage system. Successful exploitation leads to data loss and denial of service.
AnalysisAI
Unauthenticated remote attackers can delete arbitrary files from nexent v1.7.5.2's MinIO storage backend via an unprotected DELETE endpoint, leading to data loss and denial of service. The /storage/{object_name:path} API lacks authentication, authorization, and input validation (CWE-552). CVSS 9.1 reflects critical severity, though EPSS score of 0.08% (23rd percentile) and SSVC 'exploitation: none' indicate no observed active exploitation or public exploit code at time of analysis. SSVC marks this as 'automatable: yes' with 'technical impact: partial', suggesting straightforward exploitation once discovered but limited scope beyond data integrity/availability impacts.
Technical ContextAI
This vulnerability affects the nexent backend service, which uses MinIO as its underlying object storage system. The flaw is rooted in CWE-552 (Files or Directories Accessible to External Parties), where the DELETE /storage/{object_name:path} REST API endpoint exposes file management capabilities without implementing authentication, authorization, or input validation controls. The object_name path parameter accepts user-controlled input that determines which files are deleted from MinIO storage. The lack of path sanitization enables path traversal attacks, allowing attackers to reference files outside intended directories. This architectural flaw is common in microservices that expose storage backends directly without proper access control middleware. MinIO itself is a secure S3-compatible object storage system; the vulnerability lies in nexent's insecure API implementation layer that sits in front of it. CPE data is incomplete (cpe:2.3:a:n/a:n/a) indicating missing vendor/product enumeration in NVD records.
RemediationAI
Upgrade nexent to a patched version addressing CVE-2026-31216. Vendor advisory or patch version number is not available in provided intelligence sources; consult the GitHub repository (https://github.com/ModelEngine-Group/nexent) and vendor's Notion page (https://www.notion.so/CVE-2026-31216-35d1e139318881208297f0fbd8005f68) for current patch status and release notes. Until patching is possible, implement these compensating controls: (1) Deploy authentication middleware (OAuth2, API keys, or mTLS) in front of the /storage/* endpoints to restrict access to authorized clients only-this prevents unauthenticated exploitation but requires integration effort and may break existing API consumers without credentials. (2) Use network segmentation to restrict access to nexent backend service to trusted internal networks only, blocking internet-facing exposure-effective but limits legitimate remote access scenarios. (3) Implement Web Application Firewall (WAF) rules to validate and sanitize the object_name parameter, blocking path traversal sequences (../, absolute paths) and restricting deletion operations to whitelisted paths-reduces attack surface but WAF rules may have bypass potential and require careful testing to avoid blocking legitimate operations. (4) Enable MinIO versioning and object locking features to make deletions recoverable-provides data resilience but does not prevent the attack itself and consumes additional storage.
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today