Unity Level Design Patterns skill.

• Outcome: Review
• Latest audit: Sep 10, 2026 · 11:47 PM UTC
• Version: 0.1.0

Overview

The skill is a Unity level-design helper, but its editor scripts can silently delete or overwrite existing scene work without confirmation or undo support.

Review this skill before installing into a real Unity project. Use it first in a disposable scene or a version-controlled branch, because its menu commands can remove existing lights, reflection probes, baked lighting, Player objects, and terrain data without a confirmation dialog or reliable Undo support.

A.I.G

Vulnerability Patterns

• 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
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (4)

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/LightingSetup.cs:17

Finding

Overbroad and Irreversible Lighting Object Deletion

Content

View full analysis

Vulnerability Details

File Location: scripts/LightingSetup.cs, lines 17-28
Vulnerability Type: Unsafe destructive editor operation
Risk Level: Medium

Vulnerable Code

csharp

// Remove all lights
var lights = Object.FindObjectsOfType<Light>();
foreach (var light in lights)
{
    if (light.gameObject.name.Contains("Sun") || light.gameObject.name.Contains("Light"))
        Object.DestroyImmediate(light.gameObject);
}

// Remove reflection probes
var probes = Object.FindObjectsOfType<ReflectionProbe>();
foreach (var probe in probes)
    Object.DestroyImmediate(probe.gameObject);

Technical Analysis

ClearAllLighting permanently deletes complete GameObjects using Object.DestroyImmediate without registering the operation with Unity's Undo system or requesting user confirmation. Light selection is based on broad, case-sensitive substring matching against "Sun" and "Light", rather than verifying that an object was created and is owned by this tool.

The method also deletes every discovered reflection-probe GameObject without any ownership check. Because the entire GameObject is destroyed, unrelated components, scripts, children, and project-specific configuration attached to matching objects are removed as well.

This is an unsafe editor-coding practice rather than privilege escalation: the command operates with the permissions of the Unity Editor user and does not obtain additional system privileges.

Attack Path

1. A scene contains customized light objects whose names include "Sun" or "Light", or contains reflection probes.
2. Those GameObjects contain valuable components, child objects, or scene configuration unrelated to this skill.
3. The user invokes Level Design/Lighting/Clear Lighting, either directly or as part of a workflow.
4. The method scans the scene and immediately destroys all matching light GameObjects and all reflection-probe GameObjects. ...[truncated 603 chars]

Remediation

View remediation

Remediation Suggestions

• Replace Object.DestroyImmediate with Undo.DestroyObjectImmediate for editor-initiated deletion.
• Require explicit confirmation before bulk removal, using EditorUtility.DisplayDialog.
• Track tool-created objects with a dedicated marker component, stable identifier, or parent hierarchy.
• Delete only objects proven to be owned by the tool rather than relying on name substrings.
• Consider removing only the intended Light or ReflectionProbe component when deleting the complete GameObject is unnecessary.
• Register all created replacement objects with Undo.RegisterCreatedObjectUndo.
• Mark the affected scene dirty and document the exact deletion scope before execution.

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/SceneSetupWizard.cs:142

Finding

Scene Setup Irreversibly Deletes All Existing Directional Lights

Content

View full analysis

Vulnerability Details

File Location: scripts/SceneSetupWizard.cs, lines 142-148
Vulnerability Type: Unsafe destructive editor operation
Risk Level: Medium

Vulnerable Code

csharp

// Clear existing lights
var existingLights = Object.FindObjectsOfType<Light>();
foreach (var light in existingLights)
{
    if (light.type == LightType.Directional)
        Object.DestroyImmediate(light.gameObject);
}

Technical Analysis

The scene-setup workflow removes every discovered directional-light GameObject before creating its own light. It does not distinguish tool-generated lights from user-created or package-managed lights. The use of Object.DestroyImmediate bypasses Unity Undo registration, and no confirmation or preview of affected objects is presented.

Destruction applies to the complete GameObject, not only its Light component. Consequently, other components and child objects attached to a directional-light object may also be lost. The operation exceeds the minimum modification necessary to configure scene lighting.

Attack Path

1. A Unity scene contains one or more customized directional-light GameObjects.
2. A directional-light GameObject also contains project-specific components, scripts, metadata, or children.
3. The user invokes a quick scene-setup command that calls SetupLighting.
4. The method discovers every active directional light and destroys each complete GameObject immediately.
5. A replacement light is created, but the deleted custom configuration and attached objects are not preserved.
6. The user cannot reliably reverse the deletion through Unity Undo because the operation was not registered.

Impact Assessment

The issue may destroy all active directional-light objects and any associated components or hierarchy in the open scene. The scope is the Unity scene available to the current editor process. No additional privileges are acquired, but project i ...[truncated 44 chars]

Remediation

View remediation

Remediation Suggestions

• Use Undo.DestroyObjectImmediate instead of Object.DestroyImmediate.
• Restrict removal to directional lights created by this tool, identified through a marker component or tracked hierarchy.
• Prompt the user before replacing existing lighting and list the number of objects that will be affected.
• Prefer modifying or disabling an existing suitable directional light rather than deleting its GameObject.
• If only the light must be removed, preserve the GameObject and unrelated attached components.
• Register newly created lights through Undo.RegisterCreatedObjectUndo.
• Group replacement operations into a single Unity Undo group so the complete setup can be reverted atomically.

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/SceneSetupWizard.cs:211

Finding

Scene Wizard Irreversibly Deletes an Existing Player Object by Name

Content

View full analysis

Vulnerability Details

File Location: scripts/SceneSetupWizard.cs, lines 211-214
Vulnerability Type: Unsafe destructive editor operation
Risk Level: Medium

Vulnerable Code

csharp

// Check if player already exists
var existingPlayer = GameObject.Find("Player");
if (existingPlayer != null)
    Object.DestroyImmediate(existingPlayer);

Technical Analysis

The wizard treats any active GameObject named Player as disposable, without determining whether it was created by this tool. It then destroys the complete object immediately and without Unity Undo registration or user confirmation.

Name-based ownership is unreliable because Player is a conventional name used by many projects. A matching object can contain a customized controller, inventory, networking state, child hierarchy, camera, or other project-specific components. All of these are removed with the parent GameObject.

Attack Path

1. A project contains a customized active GameObject named Player.
2. The user runs a basic or themed scene-setup command that creates a player controller.
3. CreatePlayerController locates the existing object solely by name.
4. The complete existing player hierarchy is destroyed immediately.
5. The wizard creates a minimal replacement player that does not preserve the deleted configuration.
6. Since the deletion was not registered with the Unity Undo system, restoration may require version control or backup recovery.

Impact Assessment

The issue can cause loss of the active scene's existing player object, attached gameplay components, and child hierarchy. It operates only with the current user's Unity Editor access and does not grant elevated operating-system privileges.

Remediation

View remediation

Remediation Suggestions

• Do not infer tool ownership from the generic object name Player.
• Add a dedicated marker component to player objects generated by the wizard.
• If an unrelated player already exists, offer the user choices to reuse it, create another object, or explicitly replace it.
• Use Undo.DestroyObjectImmediate for any confirmed replacement.
• Register the replacement player and its child camera with Undo.RegisterCreatedObjectUndo.
• Preserve or migrate relevant configuration when replacing a tool-owned player.
• Group creation and deletion into one atomic Undo operation.

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/PlayerSetup.cs:15

Finding

Controller Setup Commands Irreversibly Delete an Existing Tagged Player

Content

View full analysis

Vulnerability Details

File Location: scripts/PlayerSetup.cs, lines 15-18, 55-58, and 96-99
Vulnerability Type: Unsafe destructive editor operation
Risk Level: Medium

Vulnerable Code

The FPS controller setup contains:

csharp

// Remove existing player
var existing = GameObject.FindWithTag("Player");
if (existing != null)
    Object.DestroyImmediate(existing);

The third-person controller setup repeats the same operation:

csharp

// Remove existing player
var existing = GameObject.FindWithTag("Player");
if (existing != null)
    Object.DestroyImmediate(existing);

The top-down controller setup also repeats it:

csharp

// Remove existing player
var existing = GameObject.FindWithTag("Player");
if (existing != null)
    Object.DestroyImmediate(existing);

Technical Analysis

All three controller-creation commands locate an existing object through the standard Unity Player tag and destroy the complete GameObject immediately. A tag identifies gameplay purpose, not ownership by this editor tool. Therefore, an unrelated customized player can be deleted even when it was created manually or by another package.

The operation does not request confirmation and does not call Undo.DestroyObjectImmediate. The replacement controller is a basic prototype and does not preserve scripts, serialized configuration, children, cameras, inventory objects, networking components, or other data from the deleted player.

GameObject.FindWithTag returns one matching active object, so behavior can also be ambiguous in scenes containing multiple tagged player objects.

Attack Path

1. A scene contains a customized active GameObject tagged Player.
2. The user invokes any of the FPS, third-person, or top-down controller creation menu commands.
3. The command finds one active object carrying the Player tag.
4. It immediately destroys that object's complete hierarchy. 5 ...[truncated 544 chars]

Remediation

View remediation

Remediation Suggestions

• Use a marker component or generated-object identifier instead of the generic Player tag to establish ownership.
• Prompt the user before replacing an unrelated tagged player.
• Offer non-destructive alternatives such as selecting the existing player, creating a uniquely named prototype, or adding only missing components.
• Replace Object.DestroyImmediate with Undo.DestroyObjectImmediate after explicit confirmation.
• Register all created parent and child objects through Unity's Undo API.
• Preserve existing serialized settings and child objects when converting between controller types.
• Validate scenes containing multiple Player-tagged objects and require the user to select the intended target.

SkillSpector

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (10)

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 95% confidence

Finding

The menu action deletes Light and ReflectionProbe scene objects immediately via DestroyImmediate, based only on object name matching, and provides no confirmation, undo registration, or scope limitation. In an editor automation skill, this can cause unintended permanent scene modification and data loss if invoked accidentally or against scenes containing important objects with matching names.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 94% confidence

Finding

Multiple lighting setup commands call ClearAllLighting as a hidden side effect, so choosing a preset silently destroys existing lights and probes before applying new settings. In the Unity level-design context this is more dangerous because these editor menu items are meant for rapid iteration and may be used on valuable in-progress scenes, making accidental destructive changes likely.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 91% confidence

Finding

Clearing baked lighting removes generated lighting data immediately without confirmation or undo, which can discard time-consuming bake results and disrupt scene state. While not an exploit in the classic sense, it is a destructive editor operation that can cause material workflow and asset loss when triggered unintentionally.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 95% confidence

Finding

This editor action destroys any existing object tagged "Player" immediately when the menu item is invoked, with no confirmation, undo registration, or validation that the object was created by this tool. In a Unity Editor workflow, that can cause accidental loss of scene content or prefab state and is especially risky because it targets by a broad tag rather than a tool-owned marker.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 95% confidence

Finding

This menu action has the same unsafe behavior: it finds any object tagged "Player" and deletes it immediately. Because scene-authoring tools are often run interactively by designers, an overly broad destructive action can unintentionally remove legitimate work and disrupt the project.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 95% confidence

Finding

This top-down setup routine also performs unconditional deletion of the current Player-tagged object without user acknowledgement. In the context of a level-design automation skill, destructive editor operations are more dangerous because they may be triggered during routine prototyping and can silently overwrite intended scene setup.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 95% confidence

Finding

The wizard enumerates existing lights and immediately destroys all directional light GameObjects, which can irreversibly modify an open scene without informed user consent. In an editor automation tool this is more dangerous because artists may run it on valuable scenes, causing data loss or disruption to lighting setups.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 96% confidence

Finding

The code finds any object named "Player" and destroys it immediately, regardless of whether it was created by this tool, which can delete legitimate scene content unexpectedly. In a level-design skill this is especially risky because "Player" is a common object name, making accidental destructive edits likely during normal editor use.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 89% confidence

Finding

The flagged code overwrites the entire terrain heightmap via SetHeights with no confirmation, undo registration, or backup path. In a Unity Editor automation skill, this can cause accidental irreversible loss of level-design work if invoked on the wrong terrain or with unexpected parameters, making it a real safety issue even though it is not a traditional exploit primitive.

Content

No source excerpt is available for this finding.

Missing User Warnings

Low

• Category: Not specified by scanner
• Confidence: 90% confidence

Finding

This code creates a new asset at a fixed project path via AssetDatabase.CreateAsset, which modifies user project data. Although the method name implies scene setup and there are internal comments, there is no confirmation prompt or user-facing disclosure at the point of the write describing that a project asset will be created.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.