| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Unauthenticated Broken Access Control in WooCommerce Multivendor Marketplace – REST API <= 1.6.3 versions. |
| Unauthenticated SQL Injection in SendPress Newsletters <= 1.26.1.20 versions. |
| Unauthenticated Broken Access Control in Advanced Posts Listing – Show Post List Easily <= 1.0.8 versions. |
| Unauthenticated PHP Object Injection in GDPR Framework By Data443 <= 2.5.0 versions. |
| Unauthenticated Settings Change in TrueBooker <= 1.2.9 versions. |
| Unauthenticated Cross Site Scripting (XSS) in Blog, Posts and Category Filter for Elementor <= 2.1.0 versions. |
| Unauthenticated Cross Site Scripting (XSS) in CF7 Views – Complete Entry Management for Contact Form 7 <= 3.2.6 versions. |
| Unauthenticated SQL Injection in Newsletter Subscription Form – User Subscriptions Form, Capture Email <= 1.5.9 versions. |
| Unauthenticated Sensitive Data Exposure in SafeSnap – Verified WordPress Backup & Restore <= 2.1.2 versions. |
| Unauthenticated Broken Access Control in WXD Backup Lite <= 1.0.2 versions. |
| Unauthenticated Sensitive Data Exposure in Museder RestoreOne <= 2.7.276 versions. |
| Unauthenticated Sensitive Data Exposure in Norvis Backup <= 1.1.0 versions. |
| Unauthenticated Sensitive Data Exposure in Snapshotify – All-in-One Backup & Restore & Migrate <= 1.3.2 versions. |
| Backstage is an open framework for building developer portals. Prior to 3.3.1, 3.4.1, 4.0.3 and 4.1.0, the @backstage/plugin-scaffolder-backend package is affected by scaffolder action input authorization bypass. An authenticated user with access to affected Scaffolder templates could bypass configured action restrictions. Depending on integration credentials, this could grant unauthorized access to repositories and related source-control resources. This issue is fixed in versions 3.3.1, 3.4.1, 4.0.3 and 4.1.0. |
| Requesting a user or organization profile page (`GET /{username}`) with an `Accept: application/rss+xml` or `Accept: application/atom+xml` header returned the owner's activity feed without the visibility check that the profile page and the `.rss` and `.atom` routes apply. Anonymous users, restricted users and non-members could confirm the existence of limited or private users and private organizations and read their profile details and public activity, also when `[other] ENABLE_FEED` was disabled. Activity in private repositories was not included. |
| The Gitea API endpoint `GET /api/v1/repos/{owner}/{repo}/media/{filepath}` wrote files of up to 1 KiB that are stored directly in Git, not in LFS, to the response without the content type and disposition headers Gitea uses for user content. An HTML file committed to a repository was therefore rendered by the browser on the Gitea origin. A user who can push to a repository could run JavaScript in the session of a victim who opens the media URL and act with the victim's permissions. |
| With `[repository] FORCE_PRIVATE = true`, Gitea creates new repositories as private, but the post-receive hook still applied the `repo.private=false` push option to an empty repository created by push. Any user who can create repositories could make their new repository public in violation of the instance policy. The default configuration is not affected. |
| The Gitea API routes for issue attachments (`/api/v1/repos/{owner}/{repo}/issues/{index}/assets/{attachment_id}`) also accepted attachments that belong to comments on the issue. Because the author of an issue may edit and delete the issue's attachments, a user who opened an issue could rename or delete attachments that other users had posted in comments on that issue. The contents of the attachments could not be changed. |
| The Gitea web route for deleting tags (`POST /{owner}/{repo}/tags/delete`) requires only write access to the Code unit, but shares its handler with release deletion and did not check that the target was a plain tag. A collaborator with Code write access and without Releases write access could permanently delete published releases of that repository, including their attachments. Protected tag rules covering the release tag still blocked the deletion. |
| When migrating a repository from another Gitea instance, Gitea used the page size reported in the source server's API settings to end its paginated downloads. A source that reported `max_response_items` as `0` made these loops run indefinitely and grow server memory until it was exhausted. Any user who can migrate repositories could point a migration at a server they control and cause a denial of service. |
