Skip to content

Merge branch 'bugfix' into fix_questionnaireg

abf06e1
Select commit
Loading
Failed to load commit list.
Closed

🐛 fix create questionnaire with empty survey #13717

Merge branch 'bugfix' into fix_questionnaireg
abf06e1
Select commit
Loading
Failed to load commit list.
DryRunSecurity / General Security Analyzer succeeded Nov 17, 2025 in 2m 25s

DryRun Security

Details

General Security Analyzer Findings: 4 detected

⚠️ Excessive JIRA API Calls dojo/jira_link/helper.py (click for details)
Type Excessive JIRA API Calls
Description The push_finding_group_to_jira function now iterates over all findings within a group and calls update_jira_issue for each. This means that for a finding group with N findings, there will be N+1 calls to JIRA (N for individual findings and 1 for the group). If N is large, this can lead to an excessive number of API calls, potentially causing rate limiting or denial of service for the JIRA integration.
Filename dojo/jira_link/helper.py
CodeLink
for finding in finding_group.findings.filter(jira_issue__isnull=False):
update_jira_issue(finding, *args, **kwargs)
⚠️ Insecure Direct Object Reference (IDOR) dojo/finding/helper.py (click for details)
Type Insecure Direct Object Reference (IDOR)
Description The post_process_findings_batch function processes a list of finding_ids without verifying that the user (which defaults to None in the observed call sites) has the necessary permissions to access or modify each finding. The get_finding_models_for_deduplication function, called by post_process_findings_batch, fetches findings solely based on their IDs, without any user-specific authorization. This allows for unauthorized modification or access to findings if an attacker can control the finding_ids supplied to this batch processing function.
Filename dojo/finding/helper.py
CodeLink
@dojo_async_task
@app.task
def post_process_findings_batch(finding_ids, *args, dedupe_option=True, rules_option=True, product_grading_option=True,
issue_updater_option=True, push_to_jira=False, user=None, **kwargs):
⚠️ Potential Command Argument Injection dojo/management/commands/clear_celery_queue.py (click for details)
Type Potential Command Argument Injection
Description The clear_celery_queue management command takes a --queue argument directly from user input. This queue_name is then used without any validation or sanitization in Celery broker operations, specifically channel.queue_declare and channel.queue_purge. While management commands are typically run by trusted users, if this command were ever exposed to untrusted input, a malicious queue_name could potentially lead to a denial of service by purging unintended queues or causing errors in the Celery broker.
Filename dojo/management/commands/clear_celery_queue.py
CodeLink
queue_name = options["queue"]
dry_run = options["dry_run"]
force = options["force"]
⚠️ Potential Resource Exhaustion via Configuration dojo/management/commands/dedupe.py (click for details)
Type Potential Resource Exhaustion via Configuration
Description The IMPORT_REIMPORT_DEDUPE_BATCH_SIZE setting, which controls the batch size for deduplication tasks, can be configured to an arbitrarily low value (e.g., 1). While this setting is intended for administrators, if an attacker gains administrative access, they could set this value to 1. This would cause the system to create a large number of small tasks and perform many more database queries for deduplication, potentially leading to significant resource exhaustion and denial of service, especially in environments with a high volume of findings.
Filename dojo/management/commands/dedupe.py
CodeLink
batch_max_size = getattr(settings, "IMPORT_REIMPORT_DEDUPE_BATCH_SIZE", 1000)
total_findings = findings_queryset.count()
logger.info(f"Processing {total_findings} findings in batches of max {batch_max_size} per test ({mode_str})")