ShipIt Clean — 6d09226a9177

Total Findings

Critical

High

Medium

Low

main @ c91de5f

AIAI Threat Analysis

REAL THREATS

Unauthenticated Network Services (Critical)

• dnsmasq-web REST API (findings 0,1,13,14,16,17,18,19): The web service (dnsmasq-web) binds to all interfaces (:867) by default with no authentication mechanism. This exposes DHCP lease management and client data to unauthenticated network access, allowing attackers to view/modify network configurations and potentially disrupt DHCP services.

Supply Chain & Integrity Issues (Critical/High)

• Binary download without verification (2,3,15): The dnsmasq-web binary is downloaded from GitHub without checksum verification, making it vulnerable to MITM attacks or repository compromise.

• SQLite database initialization without integrity verification (9): Database schema is applied without validation, potentially allowing SQL injection during initialization.

Data Exposure & Integrity (High)

• Unencrypted database at rest (6,30,36): The SQLite DHCP lease database stores sensitive network topology data (MAC addresses, IPs, hostnames) without encryption, exposing it if the filesystem is compromised.

• Unbounded database growth (7): The requests table grows indefinitely without cleanup, leading to disk exhaustion.

• Overly permissive database file permissions (8): Database files have world-readable permissions (0660), potentially exposing sensitive data to other users on the system.

Input Validation & Error Handling (High)

• Unvalidated access to ansible_facts (5,10): DHCP and DNS configuration tasks access ansible_facts[item]['ipv4'] and ansible_facts['default_ipv4']['interface'] without validation, causing failures if interfaces are missing or misconfigured.

• DNS hosts file accepts unvalidated input (11): The DNS hosts file content is copied directly without validation, potentially allowing injection of malicious DNS records.

ATTACK CHAINS

1. Network Reconnaissance → DHCP/DNS Manipulation: An attacker scans the network, discovers the exposed dnsmasq-web API (port 867), and uses the unauthenticated REST endpoints to:

- View all DHCP leases and client information (MAC addresses, IPs, hostnames) - Modify DHCP reservations to redirect traffic or perform MITM attacks - Disrupt DHCP services by deleting/modifying configurations

2. Supply Chain Compromise → Persistent Backdoor: If the GitHub repository or download is compromised, an attacker could replace the dnsmasq-web binary with a malicious version that:

- Provides backdoor access to the DHCP/DNS server - Exfiltrates network topology data from the unencrypted SQLite database - Manipulates DNS responses for phishing attacks

3. Privilege Escalation via File Permissions: A low-privileged user on the system can read the world-readable SQLite database (0660 permissions) to gather network intelligence, then use that information to:

- Target specific devices on the network - Potentially modify DHCP configurations if they gain dnsmasq group access

VERDICT

Immediate fixes required:

1. Implement authentication for the dnsmasq-web REST API (critical)

2. Add integrity verification for downloaded binaries using checksums (critical)

3. Restrict network binding to localhost or specific interfaces (high)

4. Encrypt the SQLite database or restrict access more aggressively (high)

5. Implement input validation for ansible_facts access and host file content (high)

6. Add database cleanup for the unbounded requests table (high)

The collection has serious security flaws that would expose network infrastructure to compromise. The unauthenticated web API combined with network exposure is particularly dangerous in production environments.

20 raw scanner findings — 4 critical · 12 high · 1 medium · 3 low

▶ Raw Scanner Output — 53 pre-cleanup findings

⚠ Pre-Cleanup Report
This is the raw, unprocessed output from all scanner agents before AI analysis. Do not use this to fix issues individually. Multiple agents attack from different angles and frequently report the same underlying vulnerability, resulting in significant duplication. Architectural issues also appear as many separate line-level findings when they require a single structural fix.

Use the Copy Fix Workflow button above to get the AI-cleaned workflow — it deduplicates findings, removes false positives, and provides actionable steps. This raw output is provided for transparency and audit purposes only.

HIGHUnvalidated access to ansible_facts[item]['ipv4']

[redacted]/main.yaml:15

[AGENTS: Pedant]correctness

The loop iterates over dnsmasq_dhcp_interfaces and accesses ansible_facts[item]['ipv4']['address'] and ansible_facts[item]['ipv4']['prefix'] without validating that ansible_facts[item] exists or contains ipv4 data. If the interface doesn't have IPv4 configuration, this will cause a KeyError.

Suggested Fix

Add validation: when: ansible_facts[item] is defined and ansible_facts[item]['ipv4'] is defined

HIGHUnencrypted database at rest

[redacted]/main.yaml:40

[AGENTS: Compliance]data_encryption

The SQLite database stores DHCP lease information including MAC addresses, IP addresses, and client data. The database file is stored with mode 0660 but is NOT encrypted at rest. This violates SOC 2 CC6.6 (encryption of sensitive data) and could expose network topology information.

Suggested Fix

Enable SQLite encryption or use FUSE-based encrypted storage for the database. Add encryption configuration variables.

HIGHUnbounded Database Growth - Disk Exhaustion

[redacted]/main.yaml:52

[AGENTS: Siege]dos

The 'requests' table in the SQLite database schema is documented as growing infinitely with no cleanup mechanism. Each DHCP request creates a new row. Under high traffic, this will exhaust disk space, causing the entire DHCP service to fail. No retention policy, archiving, or cleanup is implemented.

Suggested Fix

Implement database cleanup with TTL-based expiration. Add a cron job or systemd timer to archive/delete old request records. Set a maximum row count threshold with automatic purging.

HIGHSQLite database file permissions too permissive

[redacted]/main.yaml:53

[AGENTS: Infiltrator]data_exposure

Database file permissions set to '0660' allowing group read access. Combined with the web API that can read lease data, this could expose internal network topology, client MAC addresses, IP assignments, and potentially sensitive host information to unauthorized users with group access.

Suggested Fix

Restrict database file permissions to '0600' or '0640' with owner-only read access. Ensure only dnsmasq user can access the database file.

HIGHSQLite database initialization without integrity verification

[redacted]/main.yaml:22

[AGENTS: Supply]supply_chain

The SQLite database is initialized using stdin injection without any integrity checks on the database file. Malicious database files could be pre-populated with backdoors or malicious queries.

Suggested Fix

Add database integrity check using PRAGMA integrity_check after initialization. Implement database schema validation before accepting connections.

HIGHUnvalidated access to ansible_facts['default_ipv4']['interface']

[redacted]/main.yaml:15

[AGENTS: Pedant]correctness

The task accesses ansible_facts['default_ipv4']['interface'] without checking if ansible_facts['default_ipv4'] exists. If the target system has no IPv4 interface (e.g., IPv6-only, no network), this will cause an Ansible runtime error when trying to access a non-existent key.

Suggested Fix

Add a check before accessing the interface: when: ansible_facts['default_ipv4'] is defined and dnsmasq_dns_interfaces is defined and dnsmasq_dns_interfaces == 'default'

HIGHDNS hosts file accepts unvalidated input

[redacted]/main.yaml:18

[AGENTS: Infiltrator]trust_boundary

dnsmasq_dns_hosts variable accepts arbitrary host entries without validation. Malicious entries could create DNS spoofing entries, redirect traffic to attacker-controlled servers, or cause DNS resolution failures. No IP address format validation or duplicate detection.

Suggested Fix

Add IP address validation for host entries. Implement duplicate detection. Add allowlist for permitted domains/IPs. Validate against RFC standards.

HIGHdnsmasq-web API listens on all interfaces by default

[redacted]/main.yml:6

[AGENTS: Gateway - Lockdown]network_exposure

**Perspective 1:** The default listen_address is ':867' which binds to all network interfaces (0.0.0.0). This exposes the REST API to any network the server is connected to, including potentially untrusted networks. An attacker could access the API to modify DHCP leases or query sensitive client data. **Perspective 2:** The dnsmasq-web service listens on port 867 with no validation or customization. Non-standard ports may bypass security monitoring tools and lack proper firewall rules. No authentication or rate limiting is configured for this web API.

Suggested Fix

Set dnsmasq_web_listen_address to a specific interface like '127.0.0.1:867' or '192.168.1.1:867' for internal use only, and implement firewall rules to restrict access.

HIGHUnauthenticated REST API exposed on port 867

[redacted]/main.yml:8

[AGENTS: Harbor]network

The dnsmasq-web service listens on port 867 with no authentication mechanism configured. If this service is exposed to untrusted networks, attackers could access DHCP lease data, client information, and potentially manipulate DHCP configurations.

Suggested Fix

Implement authentication (API keys, OAuth, or basic auth) for the dnsmasq-web REST API. Consider binding to localhost or a private network interface if external access is not required.

HIGHBinary download without integrity verification

[redacted]/main.yml:30

[AGENTS: Gateway]supply_chain

The dnsmasq-web binary is downloaded from GitHub releases without checksum validation or signature verification. An attacker could potentially compromise the release URL or inject malicious binaries.

Suggested Fix

Add SHA256 checksum verification after download. Consider using GPG signature verification for the release artifacts.

HIGHWeb Service Bound to All Network Interfaces

[redacted]/main.yml:41

[AGENTS: Razor]network

The dnsmasq-web service binds to port 867 without specifying an IP address, making it accessible on all network interfaces. Combined with the lack of authentication, this creates a potential attack surface if the server is reachable from untrusted networks.

Suggested Fix

Set dnsmasq_web_listen_address to a specific IP (e.g., '127.0.0.1:867' or management network IP) and restrict access via firewall rules.

HIGHUnauthenticated REST API endpoint

[redacted]/main.yml:65

[AGENTS: Compliance]access_control

The dnsmasq-web service exposes a REST API on port 867 with no authentication mechanism. This violates SOC 2 CC6.1 (logical access security) and PCI-DSS 8.1 (restrict access to cardholder data). Any client can query or modify DHCP leases and client data.

Suggested Fix

Implement authentication (API key, OAuth, or basic auth) for the dnsmasq-web service. Add authentication configuration variables and middleware.

HIGHUnauthenticated Web API - DoS Vector

[redacted]/main.yml:65

[AGENTS: Siege]dos

The dnsmasq-web service is installed without authentication. Any client can connect to port 867 and query/manipulate DHCP lease data. This enables denial of service via: (1) flooding the API with concurrent requests, (2) exhausting memory by querying all leases, (3) disk exhaustion by creating excessive lease entries. No rate limiting or authentication is configured.

Suggested Fix

Add authentication (API key, token, or basic auth) to the dnsmasq-web service. Implement rate limiting on the API endpoint. Add request timeouts to prevent connection exhaustion.

HIGHdnsmasq-web REST API has no authentication mechanism

[redacted]/main.yml:68

[AGENTS: Lockdown]authentication

The dnsmasq-web service is installed and started without any authentication configuration. The REST API can be accessed by any client that can reach the port, allowing unauthorized modification of DHCP leases, client data queries, and potential privilege escalation.

Suggested Fix

Implement authentication (API key, token-based auth, or basic auth) for the dnsmasq-web API. Add authentication configuration to the service templates and validate credentials on all API endpoints.

MEDIUMSQLite database lacks encryption at rest

[redacted]/main.yaml:2

[AGENTS: Harbor]data

The DHCP lease database stores sensitive network information (MAC addresses, IP assignments) without encryption. If the database file is compromised, all lease data is exposed in plaintext.

Suggested Fix

Enable SQLite encryption or store the database in an encrypted volume. Consider using FUSE-based encrypted filesystems for sensitive data.

MEDIUMSQLite database lacks encryption at rest

[redacted]/main.yaml:28

[AGENTS: Lockdown]data_protection

The DHCP lease database is stored in plaintext on disk. If the server is compromised, all DHCP lease information including MAC addresses and IP assignments is exposed.

Suggested Fix

Enable SQLite encryption or implement file-level encryption for the database. Add database access controls and consider implementing database backup encryption.

LOWMissing Resource Limits on Service

[redacted]/main.yaml:25

[AGENTS: Siege]dos

The dnsmasq service is started without resource limits (memory, CPU, file descriptors). Under attack, the service can consume unlimited resources. No systemd limits or cgroup restrictions are configured.

Suggested Fix

Add systemd service limits: MemoryMax, CPUQuota, and MaxTasks. Configure dnsmasq with appropriate resource limits via configuration options.

LOWMissing audit logging for configuration changes

[redacted]/main.yaml:26

[AGENTS: Compliance]audit_logging

The main role includes DHCP and DNS configuration changes but provides no audit logging mechanism. SOC 2 CC7.1 requires audit trails for access and changes. No logging of who made what configuration changes.

Suggested Fix

Add Ansible logging configuration to capture playbook execution. Implement audit logging for configuration changes to the dnsmasq service.

LOWDHCP Starvation Attack Surface

[redacted]/main.yaml:25

[AGENTS: Siege]dos

The DHCP server role has no rate limiting on lease requests. An attacker can perform DHCP starvation by rapidly requesting and releasing leases, exhausting the available IP pool. This denies service to legitimate clients. No lease rate limiting or connection throttling is implemented.

Suggested Fix

Configure dnsmasq with lease rate limiting options. Implement connection rate limiting at the Ansible level. Add monitoring for rapid lease requests and alert on anomalies.

LOWTemplate destination path validation missing

[redacted]/main.yaml:26

[AGENTS: Pedant]correctness

The template task creates a DHCP configuration file without validating that the destination directory exists. If dnsmasq_dhcp_conf_file is in a non-existent directory, the task will fail.

Suggested Fix

Add a file task before the template to ensure the destination directory exists: ansible.builtin.file: path={{ dnsmasq_dhcp_conf_file | dirname }, state=directory

LOWUnvalidated DHCP Host File Content

[redacted]/main.yaml:28

[AGENTS: Razor]input_validation

The DHCP hosts file is created from user-provided content (dnsmasq_dhcp_hosts) without validation. Malicious entries could include malformed MAC addresses, IP addresses, or hostnames that might cause dnsmasq to behave unexpectedly or be exploited for reconnaissance.

Suggested Fix

Validate MAC address format (regex pattern), IP address validity, and hostname length before writing to the hosts file.

LOWDHCP hosts directory has overly permissive permissions

[redacted]/main.yaml:36

[AGENTS: Lockdown]file_permissions

The dnsmasq_dhcp_hosts_dir is created with mode '0775' which allows group write access. This could allow any process in the dnsmasq group to modify DHCP host reservations, potentially leading to IP address hijacking or network disruption.

Suggested Fix

Change mode to '0750' or '0755' to restrict write access to owner only, and ensure only the dnsmasq user can write to this directory.

LOWSQL Schema Validation May Be Bypassed

[redacted]/main.yaml:1

[AGENTS: Razor]input_validation

While the SQL schema includes REGEXP validation for MAC and IP addresses, this validation occurs at the SQLite level. If the script template (script.j2) doesn't properly validate all inputs before executing queries, SQL injection or malformed data could be introduced through the management interface.

Suggested Fix

Add application-level validation for all inputs before passing to SQLite. Use parameterized queries instead of string concatenation.

LOWDatabase script has overly permissive mode

[redacted]/main.yaml:13

[AGENTS: Harbor]permissions

The database management script is created with mode 0750, allowing read access to the group. The script executes SQL commands and could potentially be exploited if group members have write access to the database.

Suggested Fix

Reduce script permissions to 0700 (owner only) and ensure only the dnsmasq user can execute it.

LOWDatabase management script world-readable

[redacted]/main.yaml:21

[AGENTS: Infiltrator]data_exposure

Database management script created with mode '0750' but the script contains SQL queries that could expose sensitive data. The script is executed by dnsmasq but could be accessed by other processes. Combined with the web API, this creates multiple data exposure vectors.

Suggested Fix

Restrict script permissions to '0700'. Add input validation for SQL queries. Implement audit logging for database operations.

LOWDatabase file permissions may be too permissive

[redacted]/main.yaml:24

[AGENTS: Gateway]data_access_control

SQLite database file is set to mode 0660, allowing group write access. If the dnsmasq usergroup is compromised or misconfigured, this could allow unauthorized modification of lease data.

Suggested Fix

Set database file permissions to 0640 or 0600 with proper ownership. Only grant read access to the dnsmasq process.

LOWLarge Input Attack Surface on Database

[redacted]/main.yaml:28

[AGENTS: Siege]dos

The database initialization accepts raw SQL input without validation. Malformed or extremely large SQL statements could cause memory exhaustion during parsing. No input sanitization or statement size limits are enforced.

Suggested Fix

Validate and sanitize all SQL input. Add statement size limits. Use parameterized queries where possible. Implement timeouts for database operations.

LOWDatabase script template without integrity verification

[redacted]/main.yaml:28

[AGENTS: Supply]supply_chain

The database management script is templated without any integrity verification. The script could be modified to include malicious database operations.

Suggested Fix

Add checksum verification for the script template. Sign the script after deployment and verify before execution.

LOWSQLite command lacks error handling

[redacted]/main.yaml:32

[AGENTS: Pedant]correctness

The command task to initialize the SQLite database does not check for errors. If sqlite3 is not installed or the database cannot be created, the playbook will fail silently without clear error reporting.

Suggested Fix

Add register and changed_when to capture command output and check for errors: register: db_init_result, failed_when: db_init_result.rc != 0

LOWDirectory permissions set after file creation

[redacted]/main.yaml:42

[AGENTS: Pedant]correctness

The directory permissions are set after the database file is created. This could cause race conditions on multi-threaded systems where the file is created before permissions are applied.

Suggested Fix

Set directory permissions before creating the database file, or use atomic operations to ensure proper ordering

LOWDNS Amplification Attack Surface

[redacted]/main.yaml:15

[AGENTS: Siege]dos

The DNS resolver role configures upstream servers without rate limiting. An attacker can exploit this as a DNS amplification attack source by spoofing victim IPs and sending queries to this server. The server will forward responses to the spoofed addresses, amplifying traffic volume.

Suggested Fix

Implement rate limiting on incoming DNS queries. Configure response rate limiting (RRL) in dnsmasq options. Add source IP validation for forwarded queries.

LOWDNS server configuration without upstream verification

[redacted]/main.yaml:15

[AGENTS: Supply]supply_chain

Upstream DNS servers are configured without any verification of their authenticity or integrity. Malicious DNS servers could be configured to redirect traffic.

Suggested Fix

Add DNSSEC validation configuration. Document and verify upstream DNS server authenticity before deployment.

LOWDNS configuration lacks security best practices

[redacted]/main.yaml:16

[AGENTS: Lockdown]dns_security

The DNS role does not enforce security options like 'no-resolv', 'bogus-priv', and 'domain-needed' by default. Without these, the DNS server may forward queries to external resolvers unnecessarily and accept private IP address queries, increasing attack surface.

Suggested Fix

Add default security options to dnsmasq_dns_options: [bogus-priv, domain-needed, no-resolv] and document these as required for production deployments.

LOWUnvalidated DNS Host File Content

[redacted]/main.yaml:20

[AGENTS: Razor]input_validation

The DNS hosts file is created from user-provided content (dnsmasq_dns_hosts) without validation. Malicious entries could contain invalid IP addresses, malformed hostnames, or entries that could be used for DNS spoofing attempts.

Suggested Fix

Validate IP address format, hostname format, and ensure entries follow proper DNS record syntax before writing to the hosts file.

LOWTemplate destination path validation missing

[redacted]/main.yaml:20

[AGENTS: Pedant]correctness

The template task creates a DNS configuration file without validating that the destination directory exists. If dnsmasq_dns_conf_file is in a non-existent directory, the task will fail.

Suggested Fix

Add a file task before the template to ensure the destination directory exists: ansible.builtin.file: path={{ dnsmasq_dns_conf_file | dirname }, state=directory

LOWPackage installation without signature verification

[redacted]/main.yaml:1

[AGENTS: Supply]supply_chain

Packages are installed via package managers (apk, dnf, zypper) without verifying package signatures. Compromised package repositories could serve malicious packages.

Suggested Fix

Ensure package manager GPG key verification is enabled. Document and verify repository GPG signatures before installation.

LOWDeprecated firewalld module usage

[redacted]/main.yaml:73

[AGENTS: Pedant]correctness

The task uses ansible.posix.firewalld which is deprecated in Ansible 2.14+. This should be ansible.builtin.firewalld for compatibility with newer Ansible versions.

Suggested Fix

Replace ansible.posix.firewalld with ansible.builtin.firewalld

LOWFirewall configuration incomplete for DHCP/DNS services

[redacted]/main.yaml:83

[AGENTS: Infiltrator]attack_surface

Firewall rules only configured for 'dhcp' and 'dns' services but no authentication or rate limiting. This allows unlimited query attempts and could enable DHCP starvation attacks, DNS amplification attacks, or DoS attacks against the network infrastructure.

Suggested Fix

Add rate limiting rules for DHCP and DNS queries. Implement connection rate limits. Add logging for suspicious activity. Consider implementing fail2ban integration.

LOWFirewall configuration lacks rate limiting

[redacted]/main.yaml:85

[AGENTS: Compliance]network_security

Firewall rules permit DHCP and DNS services but do not implement rate limiting. This creates vulnerability to DoS attacks. SOC 2 CC6.6 requires protection against denial of service.

Suggested Fix

Add rate limiting to firewall rules for DHCP and DNS services. Implement connection rate limits per client.

LOWFirewall rules only configured for non-Alpine/Debian systems

[redacted]/main.yaml:87

[AGENTS: Lockdown]firewall_configuration

Firewall configuration for DHCP and DNS services is skipped on Alpine and Debian systems. This leaves the services exposed without network-level protection on the most common Linux distributions.

Suggested Fix

Add firewall configuration for Alpine and Debian systems using their respective firewall tools (iptables/nftables for Alpine, ufw for Debian).

LOWNo rate limiting on web API service

[redacted]/main.yml:53

[AGENTS: Harbor]network

The dnsmasq-web service is started without any rate limiting configuration. This could allow denial-of-service attacks or brute-force attempts against the API endpoints.

Suggested Fix

Add rate limiting configuration to the systemd service or use nginx as a reverse proxy with rate limiting rules.

LOWdnsmasq-web service lacks logging configuration

[redacted]/main.yml:54

[AGENTS: Lockdown]logging

The dnsmasq-web service is started without any logging configuration. This makes it impossible to audit API access, detect unauthorized usage, or troubleshoot security incidents.

Suggested Fix

Add logging configuration to the systemd and openrc service templates to capture API requests and errors. Enable audit logging for sensitive operations.

LOWDependency version constraints too loose

[redacted]/runtime.yml:2

[AGENTS: Supply]supply_chain

The collection requires ansible.posix >=2.0.0 and ansible.utils >=5.0.0, which could allow vulnerable versions to be used if the collection is installed alongside other collections.

Suggested Fix

Pin specific minor versions for dependencies. Add vulnerability scanning to CI/CD pipeline.

LOWdnsmasq service lacks security hardening options

[redacted]/main.yaml:24

[AGENTS: Lockdown]service_hardening

The main dnsmasq role does not configure security-related options like 'no-tld-query', 'no-poll', or 'no-tftp' which can reduce attack surface.

Suggested Fix

Add security options to dnsmasq_dns_options and dnsmasq_dhcp_options defaults: [no-tld-query, no-poll, no-tftp, no-remote].

LOWMissing validation for dnsmasq_web_binary path

[redacted]/main.yaml:28

[AGENTS: Pedant]correctness

The role includes dnsmasq_web role when dnsmasq_web_binary is defined, but does not validate that the binary path is writable or accessible before installation.

Suggested Fix

Add validation task to check if the binary path directory exists and is writable before attempting installation

LOWDNS hosts file lacks content validation

[redacted]/main.yaml:18

[AGENTS: Gateway]configuration

The DNS hosts file is copied without validation of the content format. Malformed entries could cause DNS resolution issues or be exploited for DNS cache poisoning attempts.

Suggested Fix

Add validation for DNS host entry format before writing to the file. Validate IP addresses and hostname formats.

LOWFirewall Configuration Without Validation

[redacted]/main.yaml:78

[AGENTS: Razor]configuration

Firewall rules are enabled for DHCP and DNS services without validating that the services are actually running or that the interfaces are appropriate. This could expose services unnecessarily.

Suggested Fix

Add checks to verify services are running and interfaces are configured before enabling firewall rules.

LOWFirewall rules only apply to non-Alpine/Debian systems

[redacted]/main.yaml:87

[AGENTS: Harbor]network

Firewall configuration for DHCP and DNS services is skipped on Alpine and Debian systems. This leaves these platforms without explicit firewall protection for the services.

Suggested Fix

Add firewall configuration for Alpine and Debian systems using their respective package managers (iptables, ufw, or nftables).

CRITICALUnauthenticated Web API with Network Exposure

[redacted]/main.yml:5

[AGENTS: Razor]authentication

The dnsmasq-web service listens on all interfaces (port 867) with no authentication mechanism. The REST API can manage DHCP leases, reservations, and query client data. If this server is exposed to the network, attackers can manipulate DHCP assignments, potentially causing denial of service or network disruption.

Suggested Fix

Implement authentication (API key, token-based, or basic auth) for the dnsmasq-web service. Restrict binding to localhost or specific management network interfaces only.

CRITICALUnauthenticated REST API exposed on all interfaces

[redacted]/main.yml:7

[AGENTS: Infiltrator]attack_surface

dnsmasq_web_listen_address defaults to ':867' which binds to all network interfaces without authentication. This exposes a management API that can manipulate DHCP leases, view client data, and modify network configurations. Attackers on the same network segment can exploit this to perform DHCP spoofing, lease hijacking, or gather network intelligence.

Suggested Fix

Add authentication mechanism (API key, token, or basic auth) to dnsmasq_web API. Restrict listen_address to specific interface (e.g., '127.0.0.1:867' or specific management IP).

CRITICALUnsigned binary download without integrity verification

[redacted]/main.yml:44

[AGENTS: Supply]supply_chain

The dnsmasq-web binary is downloaded from GitHub releases without any checksum verification, signature validation, or provenance tracking. An attacker could replace the binary with malicious code that appears legitimate.

Suggested Fix

Add SHA256 checksum verification after download using ansible.builtin.uri with checksum parameter, or verify against GPG signatures from the upstream repository. Implement artifact signing for the collection itself.

CRITICALThird-party binary downloaded without integrity verification

[redacted]/main.yml:44

[AGENTS: Infiltrator]attack_surface

dnsmasq-web binary is downloaded from GitHub releases without signature verification or checksum validation. This creates a supply chain attack vector where compromised releases could inject malicious code. The binary has execute permissions (0755) and runs as a service.

Suggested Fix

Add SHA256 checksum verification after download. Consider using signed releases and verify signatures. Add code signing validation.

INFOMissing security documentation for dnsmasq_dns

[redacted]/README.md:1

[AGENTS: Infiltrator]documentation

Documentation does not mention security considerations for DNS configuration. Users may not be aware of potential risks like DNS spoofing, cache poisoning, or information disclosure through DNS queries.

Suggested Fix

Add security best practices section to README. Document recommended configurations (bogus-priv, domain-needed, no-resolv). Include warnings about external DNS exposure.

Summary

Consensus from 36 reviewer(s): Razor, Pedant, Chaos, Sentinel, Specter, Blacklist, Syringe, Sanitizer, Vault, Gatekeeper, Deadbolt, Passkey, Cipher, Warden, Compliance, Entropy, Phantom, Siege, Lockdown, Gateway, Harbor, Tripwire, Trace, Supply, Infiltrator, Fuse, Recon, Vector, Provenance, Prompt, Wallet, Mirage, Weights, Exploit, Tenant, Egress Total findings: 61 Severity breakdown: 4 critical, 16 high, 34 medium, 6 low, 1 info

Note: Fixing issues can create a domino effect — resolving one finding often surfaces new ones that were previously hidden. Multiple scan-and-fix cycles may be needed until you’re satisfied no further issues remain. How deep you go is your call.