As we progress through 2026, the integration of Generative AI and Agentic Workflows into the SDLC has shifted from a competitive advantage to an operational standard. However, this automation introduces a novel attack surface: the trust boundary between the AI agent and the organization's private data.
Recent research from Noma Security has unveiled a critical vector where public GitHub issues can be weaponized to trick Agentic Workflows into leaking proprietary code and secrets. Unlike traditional supply-chain attacks requiring compromised credentials or malicious pull requests, this attack leverages the agent's own functionality—specifically its ability to read and synthesize context across repositories—against the organization.
For SOC analysts and DevSecOps engineers, this is not a theoretical risk. If your organization utilizes GitHub Copilot Workspace or custom Actions integrated with LLMs, and those agents possess read permissions across private repositories, you are currently exposed to data exfiltration via a simple support request filed on a public repo.
Technical Analysis
Affected Platforms & Products
- GitHub Actions & Agentic Workflows: Specifically workflows utilizing
github-scriptor LLM-integrated actions (e.g., custom agents interacting with the GitHub API). - GitHub Copilot Workspace: Instances where the agent is auto-triggered on issue events.
The Vulnerability: Indirect Prompt Injection via Context Retrieval
- Mechanism: The attacker creates a standard issue on a public repository. The issue contains a crafted prompt designed to manipulate the Agentic Workflow. When the agent analyzes the issue to generate a response or code suggestion, it performs a "context retrieval" operation.
- The Failure Mode: If the workflow's token (GITHUB_TOKEN) is scoped with broad read access (e.g., default
contents: readat the org level orread:org), the agent may pull sensitive files from private repositories within the same organization to inform its answer. - Exfiltration: The agent then incorporates this private data into its comment or response on the public issue, effectively leaking secrets, proprietary logic, or internal configuration details to the attacker.
Exploitation Requirements
- Public Exposure: The organization must have at least one public repository.
- Agent Integration: A workflow or agent must be configured to act on
issues: [opened, edited]events. - Over-Privileged Token: The
GITHUB_TOKENor the OIDC token used by the agent must have read access to private repositories.
Exploitation Status Currently identified as a proof-of-concept by Noma Security. While no specific CVE (2025/2026) has been assigned to this logic flaw, the technique is actively exploitable in environments where least privilege has not been applied to workflow tokens.
Detection & Response
Detecting this requires monitoring GitHub Audit Logs for anomalous agent behavior. Since the attacker uses legitimate features (issues) and the agent uses legitimate permissions (read access), we must hunt for the outcome: private data appearing in public contexts, or agents accessing private repos immediately following public triggers.
SIGMA Rules
---
title: Potential Data Leak via Agentic Workflow on Public Issue
id: 8a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects when a known Agentic Workflow (e.g., Copilot) comments on a public issue. The comment body should be inspected for potential leakage of private internal paths or secrets.
references:
- https://thehackernews.com/2026/07/public-github-issue-could-trick-github.html
author: Security Arsenal
date: 2026/07/10
tags:
- attack.exfiltration
- attack.t1567.001
logsource:
product: github
service: audit
detection:
selection_event:
action:
- issue_comment.created
- issue_comment.edited
selection_public:
repository_public: true
selection_actor:
actor|contains:
- 'github-actions[bot]'
- 'copilot'
- 'agent'
# Keyword heuristics to identify potential private data in the output
selection_keywords:
comment_body|contains:
- 'API_KEY'
- 'PRIVATE_KEY'
- 'internal'
- '.env'
- 'config/production'
condition: selection_event and selection_public and selection_actor and selection_keywords
falsepositives:
- Legitimate support bot addressing a public bug report referencing internal docs.
level: high
---
title: Agentic Workflow Read Access to Private Repo Post Public Trigger
did: 9d3c4e5f-6a7b-8b9c-0d1e-2f3a4b5c6d7e
status: experimental
description: Detects a workflow run or heavy read access on a private repository immediately following an issue creation on a public repository by a low-reputation user.
references:
- https://thehackernews.com/2026/07/public-github-issue-could-trick-github.html
author: Security Arsenal
date: 2026/07/10
tags:
- attack.collection
- attack.t1005
logsource:
product: github
service: audit
detection:
selection_issue:
action: issue.created
repository_public: true
selection_read:
action|contains:
- 'git.clone'
- 'repository.read'
repository_public: false
filter_benign:
actor_login|endswith: '[bot]' # We focus on bot accounts doing the reading
timeframe: 5m
condition: selection_issue and selection_read and filter_benign | timeframe()
falsepositives:
- Automation updating documentation across public/private repos.
level: medium
KQL (Microsoft Sentinel / Defender)
// Hunt for Agentic Workflows commenting on public issues with indicators of private data
GitHubAuditLog
| where Action == "issue_comment.created"
| extend IsPublic = todynamic(Repository)["public"]
| where IsPublic == true
| extend Actor = ActorLogin
| where Actor contains "bot" or Actor contains "agent" or Actor contains "copilot"
| extend CommentBody = coalesce(todynamic(tostring(Comment))["body"], tostring(CommentBody))
| where CommentBody matches regex @"(private|secret|password|token|api_key|internal_config)"
| project TimeGenerated, Actor, RepositoryName, IssueNumber, CommentBody
| order by TimeGenerated desc
Velociraptor VQL
-- Hunt for GitHub CLI or Agent configurations on endpoints that might have over-privileged scopes
SELECT FullPath, Size, Mtime, Data
FROM glob(globs='/Users/*/.config/gh/**', '/root/.config/gh/**', '/home/*/.config/gh/**')
WHERE Data =~ 'oauth_token'
OR Data =~ 'workflow_scope'
OR Data =~ 'read:org'
-- Check for local agent cache that might contain leaked context
Remediation Script (Bash)
#!/bin/bash
# Remediation: Audit and Report GitHub Workflow Permissions
# Usage: ./audit_workflow_perms.sh ORG_NAME
ORG_NAME=$1
if [ -z "$ORG_NAME" ]; then
echo "Usage: $0 ORG_NAME"
exit 1
fi
echo "[+] Auditing repositories in $ORG_NAME for default workflow permissions..."
# Get list of repos
REPOS=$(gh repo list "$ORG_NAME" --limit 400 -- name --jq '.[].name')
for repo in $REPOS; do
echo "[+] Checking: $repo"
# Check default workflow permissions at the org level is harder via CLI,
# so we inspect specific workflow files for 'permissions' block.
# List workflows
WORKFLOWS=$(gh api repos/$ORG_NAME/$repo/actions/workflows --jq '.workflows[].path' 2>/dev/null)
if [ -z "$WORKFLOWS" ]; then
continue
fi
for wf in $WORKFLOWS; do
# Download workflow content
CONTENT=$(gh api repos/$ORG_NAME/$repo/contents/$wf --jq '.content' 2>/dev/null)
if [ ! -z "$CONTENT" ]; then
DECODED=$(echo "$CONTENT" | base64 -d)
# Check for 'contents: write' or missing permissions (implies default write)
if echo "$DECODED" | grep -q "contents: write"; then
echo " [!] RISK: $wf has 'contents: write' permission"
elif echo "$DECODED" | grep -q "permissions:"; then
echo " [OK] $wf has scoped permissions."
else
echo " [!] WARNING: $wf has NO permissions block (defaults to write token)."
fi
fi
done
done
echo "[!] Action Required: Explicitly set 'permissions: contents: read' in all workflow YAML files."
echo "[!] Action Required: Disable 'Read and write permissions' in Organization Settings -> Actions -> General."
Remediation
Immediate action is required to secure the CI/CD pipeline against this logical injection.
-
Principle of Least Privilege (The Silver Bullet):
- Org-Level Settings: Navigate to Settings > Actions > General. Under "Workflow permissions", select "Read repository contents and pull requests" (and uncheck "Allow GitHub Actions to create and approve pull requests"). This prevents workflows from having write access unless explicitly granted.
- Workflow-Level Hardening: Edit every workflow YAML file. Add an explicit
permissionsblock at the top level: yaml permissions: contents: read # Restrict to read-only issues: write # Only grant write if the bot must comment
-
Scope Access granularly:
- Ensure Agentic Workflows (like Copilot) are restricted to specific repositories. Do not grant the
read:orgscope to automation tokens unless absolutely necessary.
- Ensure Agentic Workflows (like Copilot) are restricted to specific repositories. Do not grant the
-
Human-in-the-Loop for Public Triggers:
- Configure workflows triggered by
issue_commentorissuesevents on public repositories to require manual approval before posting comments or accessing internal data context.
- Configure workflows triggered by
-
Output Filtering (Data Loss Prevention):
- Implement a pre-publish validation step in your agent scripts that scans the generated text for regex patterns matching keys, internal IP addresses, or specific internal paths before allowing the comment to be posted.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.