| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Private org member list leaked via /members API endpoint — incomplete fix for PR #38145 |
| rsync 3.1.0 before 3.5.0 contains an authorization bypass in auth users directive parsing. The auth users parser uses comma-only tokenization when splitting the user list, which fails to correctly handle entries of the form @Group Name where the group name contains a space. The space within the group name causes the parser to split the entry at the space boundary, discarding the deny rule associated with the group. An authenticated user whose username or group membership would be denied by an @Group Name auth users entry can connect to a restricted module because the deny rule is silently discarded during parsing. |
| Personal access token scope enforcement bypass on the repository home page (`GET /{owner}/{repo}`) discloses private repository contents |
| Public-only API token restriction is not enforced on team API routes |
| OAuth token introspection returns metadata of tokens issued to other clients (RFC 7662 section 4 violation) |
| OpenChoreo is a complete, open-source developer platform for Kubernetes. From 1.2.0-rc.1 until 1.2.0, internal/openchoreo-api/api/handlers/exec.go and internal/openchoreo-api/api/handlers/wirelogs.go authorize component:exec and wirelogs:view using the caller-supplied project query parameter instead of comp.Spec.Owner.ProjectName, allowing a user with a project-scoped grant to execute commands in and read wirelogs from components owned by other projects in the same namespace. This vulnerability is fixed in 1.2.0. |
| SiYuan before v3.7.4 contains an information disclosure vulnerability in the /api/tag/getTag endpoint that returns tag labels and occurrence counts from password-protected documents to unauthenticated readers. Attackers can enumerate tag vocabulary and internal terminology from password-protected documents by calling the tag endpoint without providing the document's publish password. |
| SiYuan versions before v3.7.4 contain an information disclosure vulnerability in the UILayout filter that fails to properly restrict administrator workspace state from publish readers. Unauthenticated attackers can retrieve the administrator's open documents, search terms, notebook paths, and private asset locations by calling the getConf endpoint without authentication. |
| rsync 3.1.0 before 3.5.0 contains an access control bypass vulnerability that allows remote attackers to circumvent hosts deny rules by inducing DNS resolution failures during hostname-based access control evaluation. When a DNS lookup for a hostname-based deny rule fails, the daemon skips the rule rather than defaulting to a deny decision, enabling attackers who can trigger DNS failures to bypass module-level IP access controls and gain unauthorized access to restricted module file trees. |
| Vendure through 3.7.1, fixed in commit f67ef5f, contains a cross-channel authorization bypass vulnerability in stock-location.service.ts and asset.service.ts update methods that allows channel-scoped administrators to modify other tenants' data. Attackers can supply global IDs of StockLocation or Asset entities from different channels to overwrite inventory locations or catalog assets belonging to other tenants without proper channel isolation validation. |
| The DuckDB AWS extension for DuckDB contains a security policy bypass vulnerability that allows any database user with SQL execution permissions to extract plaintext AWS credentials by calling the load_aws_credentials function with the redact_secret parameter set to false, circumventing the database-wide allow_unredacted_secrets=false policy. Attackers can invoke this single function to retrieve the underlying AWS credential chain including access_key_id, secret_access_key, session_token, and region in plaintext, which are immediately valid against AWS APIs and particularly impactful in managed environments where pg_duckdb is preloaded and an AWS credential chain such as IMDSv2, IRSA, ECS task role, or EC2 instance role is reachable. |
| SFTPGo prior to 2.7.4 contains a permission bypass vulnerability that allows authenticated users to circumvent per-directory access controls by creating symbolic links in a permitted directory that point to files in directories where download, upload, or overwrite permissions are denied. Attackers can exploit the create_symlinks permission combined with read and write access in one directory to read or modify files in restricted directories, as operations are authorized against the link's directory permissions rather than the dereferenced target's directory permissions. |
| A vulnerability was found in code-projects Task Management System 1.0. This affects an unknown part of the file /user/UpdateTaskStatus.php. The manipulation of the argument task_id/val results in missing authorization. It is possible to launch the attack remotely. The exploit has been made public and could be used. |
| Budibase versions 3.39.4 before 3.40.0 contain an authorization regression in the S3 attachment upload endpoint that allows BASIC users to obtain S3 PutObject presigned URLs by sending POST requests to the attachments endpoint. The route was changed from a BUILDER permission check to a TABLE/WRITE check, which BASIC users hold by default. Attackers can specify arbitrary S3 buckets in the request body to generate presigned URLs for writing to any bucket accessible by the stored IAM credentials, enabling unauthorized file uploads. |
| Incorrect authorization in .NET Framework allows an authorized attacker to elevate privileges over a network. |
| An issue was discovered in OpenStack Keystone before 29.0.2. POST /v3/credentials did not validate that the caller-supplied project_id for an EC2-type credential matched the project of the authenticating application credential. This allowed an attacker holding an unrestricted application credential for project A to create an EC2 credential targeting project B; a subsequent /v3/ec2tokens exchange would then issue a Keystone token scoped to project B while still carrying the original app_cred_id, enabling cross-project lateral movement within the credential owner's role footprint. |
| Fork-PR Actions task can read a third private repository via the collaborative-owner branch (missing fork-PR guard) |
| Incorrect Authorization (CWE-863) in Kibana can lead to unauthorized deletion of Synthetics private locations via Accessing Functionality Not Properly Constrained by ACLs (CAPEC-1). Synthetics private locations can be shared with more than one space, and deleting one removes it from every space it is shared with. The safeguard that prevented the deletion of a private location still in use evaluated only the monitors visible in the requesting user's own space, so monitors that depend on the private location in other spaces were not taken into account. As a result, an authenticated Kibana user holding the Synthetics write privilege in a single space could delete a private location that other spaces still depend on, even where the user has no access to those spaces. Deleting the private location removes the shared configuration and stops the monitors in the other spaces from running, which suppresses the availability monitoring those spaces rely on. |
| The Elastic Security capability that suggests existing field values while a user authors endpoint policy artifacts queries Elastic Defend event data with Kibana's internal Elasticsearch account instead of the account of the requesting user. Only Kibana feature privileges are verified, and the caller's Elasticsearch index privileges are not. An authenticated user who holds Elastic Security feature privileges but no read access to the Elastic Defend event indices can therefore retrieve field values from that data, including process command line arguments, which commonly contain tokens, credentials, connection strings, and other sensitive operational detail from protected hosts. |
| Kibana Agent Builder determines whether a caller owns a private agent by comparing a stable user identifier when one is recorded, and falling back to a comparison of the username when it is not. A username is not unique across Elasticsearch authentication realms, so two distinct principals that share a username in different realms are treated as the same owner. This discloses the configuration and instructions of an agent the caller does not own, and allows that agent to be altered or removed. |
