Exposure of Version-Control Repository to an Unauthorized Control Sphere

This vulnerability exists in the ERP system due to exposure of repository information through a publicly accessible .git directory. An unauthenticated remote attacker could exploit this vulnerability by accessing the exposed .git directory and retrieving repository metadata and associated files, which could allow reconstruction of the application's source code.Show less

A vulnerability in the version control of Cisco TelePresence CE Software for Cisco Touch 10 Devices could allow an unauthenticated, adjacent attacker to install an older version of the software on an affected device. This vulnerability is due to insufficient version control. An attacker could exploit this vulnerability by installing an older version of Cisco TelePresence CE Software on an affected device. A successful exploit could allow the attacker to take advantage of vulnerabilities in older versions of the software.Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.Show less

`projen` is a project generation tool that synthesizes project configuration files such as `package.json`, `tsconfig.json`, `.gitignore`, GitHub Workflows, `eslint`, `jest`, and more, from a well-typed definition written in JavaScript. Users of projen's `NodeProject` project type (including any project type derived from it) include a `.github/workflows/rebuild-bot.yml` workflow that may allow any GitHub user to trigger execution of un-trusted code in the context of the "main" repository (as opposed to that of a fork). In some situations, such untrusted code may potentially be able to commit to the "main" repository. The rebuild-bot workflow is triggered by comments including `@projen rebuild` on pull-request to trigger a re-build of the projen project, and updating the pull request with the updated files. This workflow is triggered by an `issue_comment` event, and thus always executes with a `GITHUB_TOKEN` belonging to the repository into which the pull-request is made (this is in contrast with workflows triggered by `pull_request` events, which always execute with a `GITHUB_TOKEN` belonging to the repository from which the pull-request is made). Repositories that do not have branch protection configured on their default branch (typically `main` or `master`) could possibly allow an untrusted user to gain access to secrets configured on the repository (such as NPM tokens, etc). Branch protection prohibits this escalation, as the managed `GITHUB_TOKEN` would not be able to modify the contents of a protected branch and affected workflows must be defined on the default branch.Show less