Peekaboo Linux Gnome Wayland Computer Use

• Outcome: Review
• Latest audit: Sep 16, 2026 · 9:13 AM UTC
• Version: 1.0.2

Overview

This skill openly enables powerful remote viewing and control of a GNOME desktop, but it also installs persistent control components and gives unsafe remote-access setup guidance that users should review carefully.

Install only on a machine and user account where remote screen capture and input control are explicitly authorized. Pin and review the GNOME extensions before enabling them, avoid reusing or printing RDP/Linux passwords, keep SSH/RDP LAN- or VPN-scoped, and disable lingering, ydotoold, RDP, and the extensions when the automation is no longer needed.

A.I.G

Vulnerability Patterns

• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions

Findings (4)

T03 · Remote Payload Retrieval and Execution

Error

• Location: references/peekaboo-and-rdp-setup-ubuntu-gnome-wayland.md:49
• Finding: Unpinned Remote GNOME Shell Extensions Are Retrieved and Executed<![CDATA[ ## Vulnerability Details **File Location**: `references/peekaboo-and-rdp-setup-ubuntu-gnome-wayland.md:49-59`; also `SKILL.md:83-89` **Vulnerability Type**: Mutable remote payload retrieval and supply-chain exposure **Risk Level**: High ### Vulnerable Code ```bash D=~/.local/share/gnome-shell/extensions/[e-mail] git clone --depth 1 https://github.com/siddhpant/allow-gnome-screenshot.git /tmp/ags mkdir -p "$D" && cp -r /tmp/ags/[e-mail]/* "$D/" ``` ```bash D=~/.local/share/gnome-shell/extensions/[e-mail] git clone --depth 1 https://github.com/ickyicky/window-calls.git /tmp/wc mkdir -p "$D" && cp /tmp/wc/extension.js /tmp/wc/metadata.json "$D/" ``` The primary Skill instructions contain the same unsafe installation pattern: ```bash sudo apt-get install -y gnome-screenshot D=~/.local/share/gnome-shell/extensions/[e-mail] git clone --depth 1 https://github.com/siddhpant/allow-gnome-screenshot.git /tmp/ags mkdir -p "$D" && cp -r /tmp/ags/[e-mail]/* "$D/" sudo systemctl restart gdm3 gnome-extensions enable [e-mail] ``` ### Technical Analysis The setup retrieves code from mutable default branches and immediately installs it as GNOME Shell extensions. No immutable commit hash, signed release, checksum, vendored source, or manual verification step is used. A future clone may therefore retrieve code different from the code reviewed when this Skill was audited. GNOME Shell extensions execute inside the desktop Shell context and can interact with sensitive desktop facilities. These particular extensions are deliberately granted or expose screenshot and window-management capabilities, making upstream compromise especially consequential. The behavior is related to the declared functionality, but retrieving mutable code exceeds the minimum safe installation method. The same features can be installed from reviewed, immutable re ...[truncated 1247 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin each repository to an audited immutable commit: ```bash git clone https://github.com/example/project.git /tmp/project git -C /tmp/project checkout --detach '<audited-commit-sha>' test "$(git -C /tmp/project rev-parse HEAD)" = '<audited-commit-sha>' ``` 2. Prefer signed release tags and verify the signature against a documented maintainer key. 3. Publish and verify SHA-256 hashes for every installed extension file. 4. Vendor reviewed extension sources into the Skill package where licensing permits. 5. Do not copy or enable an extension until its JavaScript and metadata have been reviewed. 6. Document the exact audited extension versions rather than references such as `master`. 7. Limit enabled extensions to the dedicated automation account and provide explicit disable/uninstall commands. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: references/peekaboo-and-rdp-setup-ubuntu-gnome-wayland.md:169
• Finding: RDP Credential Instructions Expose Passwords and Encourage Credential Reuse<![CDATA[ ## Vulnerability Details **File Location**: `references/peekaboo-and-rdp-setup-ubuntu-gnome-wayland.md:169-170,182-198` **Vulnerability Type**: Plaintext credential exposure and credential reuse **Risk Level**: High ### Vulnerable Code ```bash # 3) device credentials (generate a strong pw; store it in your password manager, don't inline) sudo grdctl --system rdp set-credentials <rdp-user> <strong-pw> ``` The guide later recommends reusing the Linux login password and displaying stored credentials: ```bash To make it feel like one login, **set the device credential equal to the target user's Linux password** so the same `user`/`password` works at both prompts: ```bash # password via STDIN — never as an arg (args leak to ps/process list and shell history) printf '%s\n' "$THE_USER_PW" | sudo grdctl --system rdp set-credentials <user> sudo systemctl restart gnome-remote-desktop.service sudo grdctl --system status --show-credentials | grep -iE 'username|password' # verify the unix login password matches (so the GDM stage takes the same pw): printf '%s\n' "$THE_USER_PW" | su <user> -c 'echo OK' ``` ``` ### Technical Analysis The argument-based `set-credentials` example contradicts the adjacent warning not to inline passwords. Once a real password replaces the placeholder, it may be recorded in shell history and can potentially be exposed through process inspection, terminal capture, audit logging, or agent transcripts. The `--show-credentials` command deliberately emits credential material to standard output. Piping it through `grep` does not protect the value and may place it in terminal logs, CI output, support bundles, or agent context. The recommendation to make the RDP device password identical to the Linux account password expands the consequences of either credential being disclosed. Compromise of a network-facing RDP credential would then also disclose the local account credential used at GDM, through PAM, and potentially for `sudo`. No hidd ...[truncated 1425 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove the argument-based password example entirely. 2. Use a hidden interactive prompt or a protected file descriptor supported by the installed `grdctl` version. 3. If STDIN is required, read the value without echo and avoid exporting it: ```bash read -r -s -p 'RDP device password: ' RDP_PASSWORD printf '\n' printf '%s\n' "$RDP_PASSWORD" | sudo grdctl --system rdp set-credentials '<rdp-user>' unset RDP_PASSWORD ``` 4. Never invoke `status --show-credentials` in routine verification. Verify only that credentials are configured, without displaying the secret. 5. Use a unique, randomly generated RDP device credential rather than the Linux login password. 6. Redact credentials from terminal transcripts, agent logs, shell history, and support bundles. 7. Restrict RDP at the firewall to explicitly trusted source addresses and rotate any credential that may already have been exposed. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/screenshot-display.py:98
• Finding: Race-Prone Temporary File Used for Sensitive Desktop Screenshots<![CDATA[ ## Vulnerability Details **File Location**: `scripts/screenshot-display.py:98-102` **Vulnerability Type**: Insecure temporary file creation **Risk Level**: Medium ### Vulnerable Code ```python def capture_full(): tmp = tempfile.mktemp(suffix=".png") subprocess.run(["gnome-screenshot", "-f", tmp], env=_env(), check=True, timeout=30) return tmp ``` The temporary file is later opened and removed without exception-safe cleanup: ```python def crop_save(rect, out): from PIL import Image tmp = capture_full() im = Image.open(tmp) x, y, w, h = rect x = max(0, x); y = max(0, y) crop = im.crop((x, y, min(x+w, im.width), min(y+h, im.height))) crop.save(out) os.unlink(tmp) return out ``` ### Technical Analysis `tempfile.mktemp()` generates a pathname but does not atomically create the file. A time-of-check/time-of-use window exists between choosing the path and asking `gnome-screenshot` to write to it. A local attacker able to predict or observe the selected path may create a file or symbolic link at that location first. The exact result depends on `gnome-screenshot`'s destination handling and filesystem protections: the operation may fail, overwrite an unintended target, expose the screenshot through an attacker-controlled path, or cause the helper to process substituted image data. The temporary screenshot can contain credentials, private communications, personal data, or privileged application content. Cleanup is also not performed in a `finally` block, so exceptions from screenshot capture, Pillow, cropping, or saving may leave the full-desktop image behind. ### Attack Path 1. The helper generates a temporary filename without creating it. 2. A local attacker observes or predicts that pathname before `gnome-screenshot` opens it. 3. The attacker creates the path or substitutes a symbolic link. 4. `gnome-screenshot` or Pillow operates on the attacker-controlled filesystem object. 5. Depending on file-openin ...[truncated 838 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Replace `tempfile.mktemp()` with atomic creation: ```python def capture_full(): fd, tmp = tempfile.mkstemp(suffix=".png") os.close(fd) os.chmod(tmp, 0o600) try: subprocess.run( ["gnome-screenshot", "-f", tmp], env=_env(), check=True, timeout=30, ) return tmp except Exception: try: os.unlink(tmp) except FileNotFoundError: pass raise ``` 2. Verify that `gnome-screenshot` safely overwrites an already-created regular file. If not, use a private temporary directory created with `TemporaryDirectory()` and validate the destination before opening it. 3. Place image processing and deletion in a `try/finally` block. 4. Validate that the temporary object is a regular file owned by the current user and not a symbolic link. 5. Use restrictive permissions and avoid leaving full-desktop screenshots in globally accessible locations. ]]>

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: references/rdp-auth-diagnosis-server-side.md:109
• Finding: RDP Troubleshooting Recommends Broad Privileged Termination of VPN Processes<![CDATA[ ## Vulnerability Details **File Location**: `references/rdp-auth-diagnosis-server-side.md:109-119` **Vulnerability Type**: Excessive privileged and security-sensitive process control **Risk Level**: Medium ### Vulnerable Code ```text If MULTIPLE different RDP clients all send zero packets, it's a system-level VPN/filter, not the app. Tells on macOS: a pile of `utun` interfaces (`ifconfig | grep -c '^utun'`), active VPNs in `scutil --nc list`, running helpers (`pgrep -fl 'nord|tailscale|warp|zscaler|vpn'`). **Fix: bounce the VPN helper(s)** — e.g. `sudo pkill -f -i nordvpn` (and/or restart Tailscale) — which rebuilds the tunnel/filter plumbing; re-test after. ``` ### Technical Analysis `sudo pkill -f -i nordvpn` searches complete process command lines case-insensitively and terminates every matching process with root authority. It is broader than restarting a known service unit and can match unrelated command lines containing the same text. More importantly, terminating a VPN or endpoint-security helper changes the host's network security posture. Traffic may be rerouted outside an expected encrypted tunnel, kill-switch behavior may change, and existing connections may be disrupted. This exceeds the minimum privileges needed to observe or diagnose an RDP path failure. The action is presented as troubleshooting rather than hidden persistence or malicious code, but an automated agent could execute it without adequately explaining or confirming the security consequences. ### Attack Path 1. An RDP connection fails or produces no packets at the server. 2. An agent or administrator follows the guide and invokes the broad command with `sudo`. 3. All root-visible processes whose full command lines match `nordvpn` are terminated. 4. VPN enforcement or filtering is disabled or enters a degraded state. 5. Subsequent network traffic may use a different route or bypass expected protections until the service recovers. 6. Unrelated matching processes may also ...[truncated 670 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove broad `sudo pkill -f` guidance. 2. Prefer read-only diagnostics such as route inspection, packet capture limited to TCP port 3389, VPN status commands, and controlled client probes. 3. If a restart is necessary, identify and restart the exact vendor service: ```bash sudo systemctl restart '<exact-vendor-service>.service' ``` 4. Require explicit user confirmation before changing VPN or endpoint-security state. 5. Warn that restarting the VPN may expose or interrupt traffic, and pause sensitive network activity first. 6. Document how to verify that the VPN, kill switch, routes, and DNS protections have recovered. 7. Avoid performing this action when the VPN is the only trusted management channel. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• Rogue Agent: Self-Modification, Session Persistence

Findings (78)

Ae1

High

• Category: analysis-evasion

Content

`references/peekaboo-and-rdp-setup-ubuntu-gnome-wayland.md`.

• Confidence: 100% confidence
• Finding: Referenced artifact was not completely inspected

Ae1

High

• Category: analysis-evasion

Content

`references/peekaboo-and-rdp-setup-ubuntu-gnome-wayland.md`.

• Confidence: 100% confidence
• Finding: Referenced artifact was not completely inspected

Ssd 3

High

• Confidence: 97% confidence
• Finding: The document provides a turnkey workflow for persistent screenshot capture, window enumeration, and synthetic input on GNOME Wayland desktops. In context, this is a powerful surveillance-and-control capability: an agent can continuously inspect private on-screen data and interact with applications as the logged-in user, which is highly sensitive if deployed outside tightly controlled environments.

Ssd 3

High

• Confidence: 95% confidence
• Finding: The guide explicitly aims to preserve agent-related user services across logout/reboot via lingering and autologin assumptions, enabling continuous desktop access over time. Persistence amplifies the harm of any compromise by allowing long-lived collection of screenshots, UI state, and possibly typed secrets without requiring repeated operator action.

Chaining Abuse

High

• Category: Tool Misuse

Content

sudo apt-get install -y ydotool
# /dev/uinput must be writable by the user. If it's not already ACL'd, add a udev rule:
#   echo 'KERNEL=="uinput", GROUP="input", MODE="0660", OPTIONS+="static_node=uinput"' \
#     | sudo tee /etc/udev/rules.d/99-uinput.rules
#   sudo usermod -aG input "$USER"   # then re-login
mkdir -p ~/.config/systemd/user
cat > ~/.config/systemd/user/ydotoold.service <<'EOF'

• Confidence: 75% confidence
• Finding: Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.

Ssd 3

High

• Confidence: 96% confidence
• Finding: The RDP section gives a direct path to exposing the login screen and user session to remote operators, including service enablement, certificate setup, credentials, and firewall opening. That substantially increases attack surface and can reveal credentials, sensitive desktop content, and session access to anyone who obtains the RDP credentials or reaches the service.

Chaining Abuse

High

• Category: Tool Misuse

Content

sudo openssl req -newkey rsa:2048 -nodes -keyout "$SYS/rdp-tls.key" \
     -x509 -days 3650 -out "$SYS/rdp-tls.crt" -subj "/CN=$(hostname)"
sudo chown gnome-remote-desktop:gnome-remote-desktop "$SYS/rdp-tls".{key,crt}
sudo chmod 600 "$SYS/rdp-tls.key"; sudo chmod 644 "$SYS/rdp-tls.crt"
# 2) enable the SYSTEM service + set TLS
sudo systemctl enable --now gnome-remote-desktop.service
sudo grdctl --system rdp set-tls-key  "$SYS/rdp-tls.key"

• Confidence: 75% confidence
• Finding: Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.

Chaining Abuse

High

• Category: Tool Misuse

Content

password** so the same `user`/`password` works at both prompts:
```bash
# password via STDIN — never as an arg (args leak to ps/process list and shell history)
printf '%s\n' "$THE_USER_PW" | sudo grdctl --system rdp set-credentials <user>
sudo systemctl restart gnome-remote-desktop.service       # apply it to the live daemon
sudo grdctl --system status --show-credentials | grep -iE 'username|password'   # readback to confirm
# verify the unix login password matches (so the GDM stage takes the same pw):

• Confidence: 90% confidence
• Finding: Piping a plaintext password into sudo grdctl is not command-injection abuse, but in context it operationalizes direct handling of reusable credentials for a remote access service. Combined with the surrounding recommendation to align the RDP credential with the Unix account password, it increases exposure of high-value secrets and normalizes insecure credential workflows.

Chaining Abuse

High

• Category: Tool Misuse

Content

sudo systemctl restart gnome-remote-desktop.service       # apply it to the live daemon
sudo grdctl --system status --show-credentials | grep -iE 'username|password'   # readback to confirm
# verify the unix login password matches (so the GDM stage takes the same pw):
printf '%s\n' "$THE_USER_PW" | su <user> -c 'echo OK'     # prints OK if the pw is correct
```
If the user's Linux password later rotates, re-run the `set-credentials` line **and restart the
service** to keep the two stages in sync.

• Confidence: 89% confidence
• Finding: Piping the user's password to su for verification is an unsafe credential-handling pattern that normalizes scripting with plaintext account passwords. Even if intended for confirmation, it increases the chance of secret exposure through shell environment leakage, operator error, terminal logging, or copy/paste into insecure contexts.

Env Variable Harvesting

High

• Category: Data Exfiltration

Content

WINDOWS_IFACE = "org.gnome.Shell.Extensions.Windows"

def _env():
    e = dict(os.environ)
    e.setdefault("XDG_RUNTIME_DIR", "/run/user/%d" % os.getuid())
    e.setdefault("DBUS_SESSION_BUS_ADDRESS", "unix:path=%s/bus" % e["XDG_RUNTIME_DIR"])
    return e

• Confidence: 60% confidence
• Finding: Code enumerates, copies, or searches environment variables for secrets. Bulk environment access can collect credentials unrelated to the skill's stated purpose.

Env Variable Harvesting

High

• Category: Data Exfiltration

Content

WINDOWS_IFACE = "org.gnome.Shell.Extensions.Windows"

def _env():
    e = dict(os.environ)
    e.setdefault("XDG_RUNTIME_DIR", "/run/user/%d" % os.getuid())
    e.setdefault("DBUS_SESSION_BUS_ADDRESS", "unix:path=%s/bus" % e["XDG_RUNTIME_DIR"])
    return e

• Confidence: 60% confidence
• Finding: Code enumerates, copies, or searches environment variables for secrets. Bulk environment access can collect credentials unrelated to the skill's stated purpose.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 98% confidence
• Finding: The skill exposes powerful shell and environment-dependent capabilities but does not declare any tool scope or permission boundary. In practice it enables screenshot capture, desktop input injection, remote SSH control, service management, and extension installation, so the absence of explicit allowed-tools/permissions creates a dangerous mismatch between stated contract and real authority.

Session Persistence

Medium

• Category: Rogue Agent

Content

non-login shells — `XDG_RUNTIME_DIR=/run/user/UID`,
  `DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/UID/bus`, `WAYLAND_DISPLAY=wayland-0`, `DISPLAY=:0`.
  (Replace `UID` with the session user's numeric id, e.g. `1000`.)
- If agents run under `systemd --user` with the full graphical session env + lingering enabled,
  they inherit all of the above and survive SSH disconnects.
- `gnome-screenshot` grabs the **full virtual desktop** (all monitors stitched). On multi-4K
  setups that's huge — use `-w` (focused window) or the per-display helper below.

• Confidence: 91% confidence
• Finding: The skill recommends running agents under `systemd --user` with lingering enabled so they survive SSH disconnects, which establishes persistence for a process that can observe and control the desktop. Persistence materially raises the security risk because a compromised or misconfigured agent can continue interacting with the session after the initiating operator disconnects.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The skill instructs remote screenshot capture and transfer over SSH/SCP without prominently warning that full desktop images may contain passwords, tokens, personal data, internal documents, or customer information. Because the capture is of the active graphical session and may include all monitors, the privacy and data-exfiltration risk is substantial even if SSH itself is encrypted.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

### Installing the extension from scratch
```bash
# [NATIVE or over SSH with the session env exported]
sudo apt-get install -y gnome-screenshot
D=~/.local/share/gnome-shell/extensions/[e-mail]
git clone --depth 1 https://github.com/siddhpant/allow-gnome-screenshot.git /tmp/ags
mkdir -p "$D" && cp -r /tmp/ags/[e-mail]/* "$D/"

• Confidence: 86% confidence
• Finding: This step invokes `sudo apt-get install`, which requires elevated privileges and expands the host's software footprint. While common for setup, embedding privileged package installation in an automation skill increases the risk of unintended system modification and broadens the consequences if the skill is misused or run on the wrong host.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

D=~/.local/share/gnome-shell/extensions/[e-mail]
git clone --depth 1 https://github.com/siddhpant/allow-gnome-screenshot.git /tmp/ags
mkdir -p "$D" && cp -r /tmp/ags/[e-mail]/* "$D/"
sudo systemctl restart gdm3      # reload the Shell so it discovers the extension (see WARNING below)
# after the session returns:
export XDG_RUNTIME_DIR=/run/user/UID DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/UID/bus
gnome-extensions enable [e-mail]

• Confidence: 97% confidence
• Finding: Restarting `gdm3` with `sudo` is a privileged action that tears down the active graphical session, potentially interrupting users, killing in-flight work, and changing session state. In a remote automation context this is especially risky because it can act like a denial-of-service against the desktop and may disrupt monitoring or recovery access.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The skill documents remote input injection into the active desktop session over SSH but lacks a clear warning that this can directly trigger destructive actions, send messages, approve prompts, modify data, or interfere with a live user's session. Since it targets the real GUI of a logged-in user, misuse can cause immediate integrity and availability impacts.

Session Persistence

Medium

• Category: Rogue Agent

Content

export XDG_RUNTIME_DIR=/run/user/UID YDOTOOL_SOCKET=/run/user/UID/.ydotool_socket
  ydotool mousemove -a 700 400; ydotool click 0xC0; ydotool type "hi"'
```
If `ydotoold.service` is down — `systemctl --user enable --now ydotoold.service`. For element
targeting (not blind coords) use the `locate-element` helper below.

## CAPABILITY B+ — Click an element by role/name (SOM via hybrid coords)

• Confidence: 88% confidence
• Finding: Enabling `ydotoold.service` as a user service creates persistent input-injection capability within the session. Although useful for functionality, persistent background control infrastructure increases the blast radius of accidental use or post-compromise abuse because GUI input injection remains readily available.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

**⚠️ #1 RDP gotcha — credential changes need a daemon restart.** `grdctl --system rdp set-credentials`
writes the keyfile but the **running daemon does NOT hot-reload it into its NTLM SAM**. Until you
`sudo systemctl restart gnome-remote-desktop.service`, NLA fails for every client:
`ntlm_fetch_ntlm_v2_hash: Could not find user in SAM database` → `SEC_E_NO_CREDENTIALS` →
`transport_accept_nla: client authentication failure`. Meanwhile `grdctl status` shows the correct
creds (it reads the file). Clients report this as **`FREERDP_ERROR_CONNECT_TRANSPORT_FAILED`** (RoyalTS)

• Confidence: 84% confidence
• Finding: The documented restart of `gnome-remote-desktop.service` is a privileged action that changes remote access availability and authentication behavior. Although presented as troubleshooting, privileged manipulation of a remote desktop service is sensitive because mistakes can expose, disable, or destabilize remote access paths.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

## Pitfalls

- The screenshot unlock is **binary-scoped** — only the `gnome-screenshot` binary is allowlisted. A raw gdbus Screenshot call still fails. Always shell out to `gnome-screenshot`.
- **Reloading the Shell on Wayland = restarting GDM** (`sudo systemctl restart gdm3`). There's no in-place `Alt+F2 r` over SSH. The **live GUI session is briefly torn down**, so don't do it mid-GUI-task. If autologin is enabled the desktop recovers in ~12s; `systemd --user` services survive if lingering is on. Verify recovery: `loginctl list-sessions` shows a `seat0` `Type=wayland Active=yes` session.
- **Never use the gdb `unsafe_mode` injection** — it crashes gnome-shell. Use the extension.
- **The `allow-gnome-screenshot` extension can silently flip to INACTIVE** (its allowlist hook only re-arms on a fresh Shell init). Symptom: `gnome-screenshot -f` exits 0 but writes no file. A disable/enable cycle is NOT enough — it needs a Shell reload (`sudo systemctl restart gdm3`) to re-arm. If you depend on capture in an automated loop, verify the file exists each time and reload-on-miss. (Window Calls can flip too — re-enable after any GDM restart.)
- `gnome-screenshot -a` (interactive area) needs a human at the screen — useless headless; use `-f` (full) or `-w` (window).

• Confidence: 95% confidence
• Finding: The skill explicitly recommends restarting `gdm3` to reload screenshot-related capabilities, which is a privileged and disruptive action affecting the active GUI session. Because the skill's purpose is unattended computer control, normalizing this step increases the chance that an agent or operator uses a high-impact administrative action as part of routine automation.

Session Persistence

Medium

• Category: Rogue Agent

Content

## Pitfalls

- The screenshot unlock is **binary-scoped** — only the `gnome-screenshot` binary is allowlisted. A raw gdbus Screenshot call still fails. Always shell out to `gnome-screenshot`.
- **Reloading the Shell on Wayland = restarting GDM** (`sudo systemctl restart gdm3`). There's no in-place `Alt+F2 r` over SSH. The **live GUI session is briefly torn down**, so don't do it mid-GUI-task. If autologin is enabled the desktop recovers in ~12s; `systemd --user` services survive if lingering is on. Verify recovery: `loginctl list-sessions` shows a `seat0` `Type=wayland Active=yes` session.
- **Never use the gdb `unsafe_mode` injection** — it crashes gnome-shell. Use the extension.
- **The `allow-gnome-screenshot` extension can silently flip to INACTIVE** (its allowlist hook only re-arms on a fresh Shell init). Symptom: `gnome-screenshot -f` exits 0 but writes no file. A disable/enable cycle is NOT enough — it needs a Shell reload (`sudo systemctl restart gdm3`) to re-arm. If you depend on capture in an automated loop, verify the file exists each time and reload-on-miss. (Window Calls can flip too — re-enable after any GDM restart.)
- `gnome-screenshot -a` (interactive area) needs a human at the screen — useless headless; use `-f` (full) or `-w` (window).

• Confidence: 80% confidence
• Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

- The screenshot unlock is **binary-scoped** — only the `gnome-screenshot` binary is allowlisted. A raw gdbus Screenshot call still fails. Always shell out to `gnome-screenshot`.
- **Reloading the Shell on Wayland = restarting GDM** (`sudo systemctl restart gdm3`). There's no in-place `Alt+F2 r` over SSH. The **live GUI session is briefly torn down**, so don't do it mid-GUI-task. If autologin is enabled the desktop recovers in ~12s; `systemd --user` services survive if lingering is on. Verify recovery: `loginctl list-sessions` shows a `seat0` `Type=wayland Active=yes` session.
- **Never use the gdb `unsafe_mode` injection** — it crashes gnome-shell. Use the extension.
- **The `allow-gnome-screenshot` extension can silently flip to INACTIVE** (its allowlist hook only re-arms on a fresh Shell init). Symptom: `gnome-screenshot -f` exits 0 but writes no file. A disable/enable cycle is NOT enough — it needs a Shell reload (`sudo systemctl restart gdm3`) to re-arm. If you depend on capture in an automated loop, verify the file exists each time and reload-on-miss. (Window Calls can flip too — re-enable after any GDM restart.)
- `gnome-screenshot -a` (interactive area) needs a human at the screen — useless headless; use `-f` (full) or `-w` (window).
- Full-desktop shots are huge (multi-4K). Prefer `-w`, or downscale before analysis.
- ydotool needs `ydotoold` alive + `YDOTOOL_SOCKET`/`XDG_RUNTIME_DIR`. Re-enable if it dies. Raw `ydotool` is blind absolute pixels — prefer `locate-element` (Capability B+) for element targeting.

• Confidence: 95% confidence
• Finding: This section reiterates that a shell reload requires `sudo systemctl restart gdm3`, again normalizing a privileged session-disrupting action inside an automation-focused skill. Repetition in operational guidance increases likelihood of misuse and elevates denial-of-service risk to the active desktop session.

Session Persistence

Medium

• Category: Rogue Agent

Content

- The screenshot unlock is **binary-scoped** — only the `gnome-screenshot` binary is allowlisted. A raw gdbus Screenshot call still fails. Always shell out to `gnome-screenshot`.
- **Reloading the Shell on Wayland = restarting GDM** (`sudo systemctl restart gdm3`). There's no in-place `Alt+F2 r` over SSH. The **live GUI session is briefly torn down**, so don't do it mid-GUI-task. If autologin is enabled the desktop recovers in ~12s; `systemd --user` services survive if lingering is on. Verify recovery: `loginctl list-sessions` shows a `seat0` `Type=wayland Active=yes` session.
- **Never use the gdb `unsafe_mode` injection** — it crashes gnome-shell. Use the extension.
- **The `allow-gnome-screenshot` extension can silently flip to INACTIVE** (its allowlist hook only re-arms on a fresh Shell init). Symptom: `gnome-screenshot -f` exits 0 but writes no file. A disable/enable cycle is NOT enough — it needs a Shell reload (`sudo systemctl restart gdm3`) to re-arm. If you depend on capture in an automated loop, verify the file exists each time and reload-on-miss. (Window Calls can flip too — re-enable after any GDM restart.)
- `gnome-screenshot -a` (interactive area) needs a human at the screen — useless headless; use `-f` (full) or `-w` (window).
- Full-desktop shots are huge (multi-4K). Prefer `-w`, or downscale before analysis.
- ydotool needs `ydotoold` alive + `YDOTOOL_SOCKET`/`XDG_RUNTIME_DIR`. Re-enable if it dies. Raw `ydotool` is blind absolute pixels — prefer `locate-element` (Capability B+) for element targeting.

• Confidence: 80% confidence
• Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Missing User Warnings

Medium

• Confidence: 89% confidence
• Finding: The opening frames the procedure as enabling agent screenshots and input on a live desktop without an immediate privacy and consent warning. Because the capability directly permits observing on-screen content and injecting actions into a user session, lack of front-loaded disclosure increases the risk of misuse or accidental deployment in environments with sensitive data.

Session Persistence

Medium

• Category: Rogue Agent

Content

# Scoped to that one D-Bus sender; does NOT enable global unsafe_mode.
D=~/.local/share/gnome-shell/extensions/[e-mail]
git clone --depth 1 https://github.com/siddhpant/allow-gnome-screenshot.git /tmp/ags
mkdir -p "$D" && cp -r /tmp/ags/[e-mail]/* "$D/"
```

## Step 2 — Window enumeration / targeting (Window Calls extension)

• Confidence: 71% confidence
• Finding: Copying a GNOME Shell extension into the user's extensions directory creates a persistent capability change that survives shell restarts and reboots once enabled. In this case the extension re-allows screenshot capture that GNOME intentionally restricts, so persistence makes the bypass enduring rather than ephemeral.

Static analysis

No suspicious patterns detected.