Do not disclose suspected vulnerabilities, exposed credentials, internal repository names, endpoint data, or organization-specific deployment details in a public issue.

Use GitHub's private vulnerability reporting feature for this repository when available. Include:

• affected WallpaperAgent version;
• affected script or component;
• Windows version and architecture;
• deployment method, such as local installation or Microsoft Intune;
• configuration relevant to the issue, with secrets removed;
• reproduction steps;
• expected and observed behavior;
• security impact;
• logs or proof of concept with sensitive values sanitized.

Do not include real publishing tokens, internal URLs, user names, device names, or proprietary wallpaper files.

Security corrections are applied to the current repository version. Older package versions may not receive backports unless explicitly documented.

Before reporting an issue, confirm that it is reproducible with the latest available version and configuration.

WallpaperAgent consists of two distinct security domains:

1. the content-publishing environment;
2. Windows endpoints consuming published content.

The endpoint agent is intentionally read-only with respect to the content repository. Repository write credentials belong only to the publishing server, portal, or automation.

The endpoint must never receive a GitHub token or another credential with content-write permission.

The following must not be committed or packaged:

• GitHub personal access tokens;
• repository deploy credentials;
• service account passwords;
• internal API keys;
• certificates with private keys;
• secrets embedded in URLs;
• production content-repository identifiers when they are considered sensitive.

PublisherTokenEnvironmentVariable contains only the name of a variable used by an external publishing process. The installed WallpaperAgent does not read or use the token.

If a token is exposed:

1. revoke or rotate it immediately;
2. review repository and audit logs;
3. remove the secret from source and Git history;
4. rebuild any package that contained it;
5. inspect endpoints and publishing systems for unauthorized changes;
6. publish a new known-good manifest and assets when content integrity is uncertain.

Use a fine-grained token with:

• access to only the required content repository;
• Contents: Read and write only;
• defined expiration;
• storage in a secret vault or protected machine-level environment variable;
• rotation procedures;
• audit logging where available.

The publishing workflow should:

• validate image types and dimensions;
• calculate SHA-256 from the final bytes;
• upload assets before updating the manifest;
• publish the manifest last;
• prevent concurrent publishers from overwriting each other;
• retain previous known-good assets for rollback;
• require authentication and authorization for administrative publication actions.

The updater treats all remote content as untrusted until validated.

Implemented controls include:

• absolute HTTPS URL requirement;
• leaf-only asset file names;
• accepted extension allowlist;
• configurable manifest and asset size limits;
• required 64-character SHA-256 values;
• SHA-256 comparison before activation;
• image decoding and dimension validation;
• unique temporary download files;
• atomic JSON state writes;
• activation only after both desktop and lock-screen assets are valid;
• preservation of the previous release after candidate failure.

SHA-256 validates integrity against the manifest. It does not establish who was authorized to publish the manifest. Protect the publishing workflow and content origin accordingly.

The update task runs as SYSTEM because it maintains machine-level files and state.

The apply task runs under the built-in INTERACTIVE group with limited privileges because it must access:

• the user's HKCU desktop configuration;
• Windows Runtime APIs associated with the current profile;
• per-user state under %LOCALAPPDATA%.

Do not change the apply task to SYSTEM as a shortcut. That would break the intended user-profile boundary and may apply settings to the wrong context.

Do not change the update task to a standard user without redesigning machine-state ownership and ACLs.

The installer removes inherited permissions from the installation root and grants:

• full control to SYSTEM;
• full control to local Administrators;
• read and execute access to local Users.

Review ACLs after changing InstallRoot or deploying to a nonstandard volume.

Standard users must not be able to replace:

• updater scripts;
• helper module;
• installed configuration;
• machine current.json;
• validated assets.

Validate the two task principals after installation:

• update task: SYSTEM, highest run level;
• apply task: built-in INTERACTIVE group, limited run level.

The tasks use 64-bit Windows PowerShell, hidden execution, execution time limits, and MultipleInstances IgnoreNew.

Unexpected changes to task action, principal, trigger, or script path should be treated as an integrity incident.

The package currently invokes Windows PowerShell with -ExecutionPolicy Bypass so it can run consistently through Intune and scheduled tasks.

Execution Policy is not a security boundary. Production environments should consider Authenticode signing and a controlled code-signing process.

Before enabling Enforce script signature check in Intune:

• sign every relevant script;
• ensure the signing certificate is trusted by endpoints;
• test installation, tasks, detection, upgrade, diagnostics, and uninstall;
• document certificate renewal and revocation.

Before uploading a package:

• build from a clean, reviewed source tree;
• confirm AgentVersion and detection version match;
• inspect the generated Source directory;
• confirm no content images or credentials are included;
• calculate and retain a hash of the final .intunewin when required by internal process;
• restrict who can modify and assign the Win32 application;
• deploy to a pilot group first.

The content repository and the Intune package have independent trust paths. Compromise of either can affect endpoints.

The agent requires HTTPS, but deployment owners remain responsible for:

• certificate trust;
• proxy configuration;
• DNS integrity;
• content-origin access controls;
• monitoring unusual download behavior;
• avoiding credentials in query strings;
• preventing untrusted users from changing ManifestUrl.

For private content, use an endpoint-safe read-only delivery mechanism. Do not place a publisher token on endpoints.

Machine and user logs may contain:

• organization name;
• user name in the per-user apply log;
• local file paths;
• release identifiers;
• image URLs;
• validation errors;
• lock-screen URIs.

Treat diagnostics as operational data. Sanitize logs before attaching them to public issues, documentation, or portfolio materials.

Wallpaper and lock-screen images may also contain confidential campaign information. Do not publish them without authorization.

Public repository configuration must use placeholders rather than production values.

Review these fields before distribution:

• OrganizationName;
• RepositoryOwner;
• RepositoryName;
• RepositoryBranch;
• RepositoryManifestPath;
• ManifestUrl;
• explicit install, registry, task, and mutex overrides.

A malicious or unauthorized configuration change can redirect endpoints to another content origin or alter privileged task behavior.

WallpaperAgent relies primarily on built-in Windows PowerShell and Windows components, including:

• Scheduled Tasks;
• System.Drawing;
• Windows Runtime lock-screen APIs;
• user32.dll desktop wallpaper API.

Windows behavior may differ by edition, build, policy, or future platform changes. Test supported baselines and review Microsoft security updates that affect these components.

Before production assignment:

1. validate source configuration;
2. validate the remote manifest;
3. review generated package contents;
4. confirm task principals and ACLs;
5. test malformed manifest, invalid hash, corrupted image, and network failure;
6. confirm the previous release remains functional;
7. test desktop and lock screen across representative devices and users;
8. validate Intune detection, upgrade, and uninstall;
9. document rollback for both package and content;
10. retain sanitized diagnostic evidence.

WallpaperAgent does not provide:

• digital signature verification for the manifest;
• endpoint authentication to a private GitHub repository;
• a content-publishing portal;
• antivirus or malware scanning of image files;
• certificate pinning;
• centralized endpoint telemetry collection;
• guaranteed lock-screen behavior against conflicting Windows policies.

Deployment owners must add controls appropriate to their risk model.

• Architecture
• Configuration
• Manifest contract
• Microsoft Intune deployment