Back to skill

Security audit

bearware-teamtalk

Security checks for vulnerabilities and agentic risk

Overview

The skill is mostly a coherent TeamTalk SDK helper, but its setup path can automatically fetch code and run privileged system-modifying build commands without clear user confirmation.

Review the shell scripts before running them. Prefer Docker or manual dependency installation, verify the GitHub repository and branch, and do not run the build helper with sudo unless you are comfortable giving the fetched build system root-level authority.

Vulnerability Patterns
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (8)

Vague Triggers

Medium
Confidence
91% confidence
Finding
The activation scope is extremely broad ('any TeamTalk-related task'), which increases the chance the skill will be invoked in contexts where its build and system-level guidance is unnecessary or risky. Overbroad routing can expose users to irrelevant file/system operations and makes prompt-injection or unsafe tool use more likely because the skill claims authority over a wide class of tasks.

Missing User Warnings

Medium
Confidence
95% confidence
Finding
The build instructions include cloning code, installing dependencies, invoking package-management-like targets, and cross-platform build steps without any warning about privilege use, network access, disk changes, or system modification. In an agent setting, this can lead to unintended execution of destructive or trust-sensitive commands on the host environment, especially because the skill presents them as quick, normal actions.

Missing User Warnings

Medium
Confidence
95% confidence
Finding
The script invokes sudo to install build dependencies via make targets without an explicit warning or confirmation that it will modify the host system. This is risky because the repository content and its Makefile targets are fetched from a remote Git source, so a user may grant elevated privileges to commands they have not reviewed.

Missing User Warnings

Medium
Confidence
91% confidence
Finding
The macOS path installs packages with Homebrew automatically and suppresses errors, but does not clearly warn the user that running the script will modify the local system. In a build helper that clones remote source, implicit package installation increases trust and supply-chain risk because users may not expect environment changes beyond building the project.

Sudo/Root Execution

Medium
Category
Privilege Escalation
Content
cd TeamTalk5

# Install dependencies then build
sudo make -C Build depend-ubuntu24
make -C Build ubuntu24

# macOS
Confidence
97% confidence
Finding
The explicit use of 'sudo make -C Build depend-ubuntu24' encourages root execution of a build target, which can run arbitrary commands defined by the fetched repository's makefiles and dependency scripts with elevated privileges. Because the same section also instructs cloning from GitHub first, the risk is amplified: a compromised repository, dependency, or typo-squatted source could result in full system compromise.

Sudo/Root Execution

Medium
Category
Privilege Escalation
Content
if grep -qi ubuntu /etc/os-release 2>/dev/null; then
            UBUNTU_VER=$(grep VERSION_ID /etc/os-release | cut -d= -f2 | tr -d '"' | tr -d '.')
            echo "Installing deps for Ubuntu $UBUNTU_VER..."
            sudo make -C Build depend-ubuntu${UBUNTU_VER} || \
                sudo make -C Build depend-ubuntu22
            echo "Building..."
            make -C Build ubuntu${UBUNTU_VER} || make -C Build ubuntu22
Confidence
94% confidence
Finding
This line runs a repository-defined make target under sudo, granting elevated privileges to commands ultimately controlled by the checked-out source tree. If the upstream repository, branch, or local environment variables are compromised, the script could execute arbitrary root-level actions during dependency installation.

Sudo/Root Execution

Medium
Category
Privilege Escalation
Content
UBUNTU_VER=$(grep VERSION_ID /etc/os-release | cut -d= -f2 | tr -d '"' | tr -d '.')
            echo "Installing deps for Ubuntu $UBUNTU_VER..."
            sudo make -C Build depend-ubuntu${UBUNTU_VER} || \
                sudo make -C Build depend-ubuntu22
            echo "Building..."
            make -C Build ubuntu${UBUNTU_VER} || make -C Build ubuntu22
        elif grep -qi debian /etc/os-release 2>/dev/null; then
Confidence
94% confidence
Finding
The fallback sudo make command has the same issue as the primary path: it executes source-controlled Makefile logic with root privileges. This expands the attack surface because even the fallback path can perform unintended privileged operations if the build scripts are altered upstream or locally.

Sudo/Root Execution

Medium
Category
Privilege Escalation
Content
echo "Building..."
            make -C Build ubuntu${UBUNTU_VER} || make -C Build ubuntu22
        elif grep -qi debian /etc/os-release 2>/dev/null; then
            sudo make -C Build depend-raspios12
            make -C Build raspios12
        else
            echo "Unsupported Linux distro. Trying direct CMake build..."
Confidence
93% confidence
Finding
This Debian path also uses sudo to run a repository-defined dependency target, creating the same privileged execution risk as the Ubuntu path. In the context of a build-from-source helper, this is more dangerous because the script first pulls code from a remote repository and then trusts that code to define root-executed behavior.

Static analysis

No suspicious patterns detected.