Redmoon

Description

This bounty is part of the Atlassian Marketplace Bounty Program Redmoon Software is a Jira add-on development company. We pride ourselves in quality, user-friendliness and good responsive service. Get Started (tl;dr version) • Do not access, impact, destroy or otherwise negatively impact Redmoon Software or Atlassian customers, or customer data in any way. • Ensure that you use your @bugcrowdninja.com email address. • Ensure you understand the targets, scopes, exclusions, and rules below – no public disclosure without prior consent. • The plugin located at the URL is in scope but the Marketplace page itself is NOT . Quick Links Comment History for Jira Cloud (Cloud version only) Custom Fields for Jira Document Vault for Jira cloud (Cloud version only) Sub Task Manager for Jira (Cloud version only) Watch It for Jira (Cloud version only) Focus Areas Below is a list of some of the vulnerability classes that we are seeking reports for: Cross Instance Data Leakage/Access** Server-side Remote Code Execution (RCE) Server-Side Request Forgery (SSRF) Stored/Reflected Cross-site Scripting (XSS) Cross-site Request Forgery (CSRF) SQL Injection (SQLi) Access Control Vulnerabilities (Insecure Direct Object Reference issues, etc) Path/Directory Traversal Issues Ensure you review the out of scope and exclusions list for further details. ** Cross Instance Data Leakage/Access refers to unauthorized data access between instances. Ratings/Rewards: For the initial prioritization/rating of findings, this program will use the Bugcrowd Vulnerability Rating Taxonomy . However, it is important to note that in some cases a vulnerability priority will be modified due to its likelihood or impact. In any instance where an issue is downgraded, a full, detailed explanation will be provided to the researcher - along with the opportunity to appeal, and make a case for a higher priority. Please see below for deviations.

Targets

Rules, Exclusions, and Scopes Any domain/property of Redmoon Software not listed in the targets section is strictly out of scope (for more information please see the out of scope and exclusions sections below). Researchers should use the "bugbounty-test-.atlassian.net" namespace provided in the instructions below. Please do not create additional instances outside of this namespace for testing. Out-of-Scope Anything not declared as a target or in scope above should be considered out of scope. However to help the following are considered out of scope. Out of scope: anything not explicitly declared in scope. &=.atlassian.com domain. Blind XSS returning unauthorized data (e.g. screenshots, cookies); use least invasive tests (e.g. 1x1 image, nonexistent page). Injecting public forms without removable payloads; check with support@bugcrowd first. Pivoting, post-exploitation, or leveraging findings to discover further issues. Redmoon Software websites. Customer cloud instances and data. Repositories you do not own. Product versions older than the latest release. Internal or development services. Expired tokens for page loads. Granularity mismatch: App project admins gaining global project updates, bypassing Jira's per-project constraints. Exploits via Watch It tracker Payload field or timed tracker pages. Unauthenticated submits/web triggers for Comment History and Document Vault (known issue). Comment History (known/in-progress): Stored XSS/HTML injection via rendering; unsafe CSP (unsafe-inline/eval); SSRF via resolvers; verbose logging/error disclosure; missing input validation on IDs; npm dependencies CVEs; missing rate limiting on resolvers; unbounded pagination. STM,Watch It,Custom Fields - Responses from /_ah/api/ endpoints return internal token fields ("forgeInvocationToken","forgeSiteUrl","forgeApiBaseUrl") to the browser, exposing the app's Forge OAuth token. Disclosure on any endpoint, and anything done with the leaked token (Jira access as the app account), are out of scope. ### STM Accessing complete template list (all users require access for bulk create/JQL). Bulk Create/update pages executing calls for unauthorized users. Pages visible to users lacking access. POST /forgeWebhook authenticates only by comparing the X-Forge-Source header to "true" and never verifies the Forge invocation token as a signed JWT (no signature/issuer/audience/expiry; falls back to any Authorization: Bearer). Cross-tenant issue manipulation, forged executor-pipeline runs, DoS, and user/cloudId spoofing via X-Forge-Cloud-Id/X-Forge-Installation-Id are out of scope. Via that unauthenticated /forgeWebhook, an attacker-supplied bearer is persisted as a tenant's Forge OAuth token (updateOAuthToken/setForgeOAuthToken) and later used for outbound Jira calls. Token poisoning, credential overwrite, and downstream effects are out of scope. The "vversion" endpoint (vversion/{id}) has no auth/authorization/licence check and is gated only by hard-coded magic GUIDs. Cross-tenant data dump, tenant/account deletion (DELETE_USER_ACCT + hellYeah=true), cross-tenant template copy, archive restore, and datastore-wide migration/deletion are out of scope. The Forge "stmProxyJira" resolver forwards caller-controlled url/method/body via api.asApp() with only a "/rest/api/" prefix check, bypassing the caller's Jira permissions. Resulting privilege escalation (arbitrary issue create/edit/transition/delete, user/group enumeration, config access) and the broader pattern of all resolvers using api.asApp() without a req.context check are out of scope. getAuditStep validates the projectId parameter but not the fetched audit job's (parentId) ownership (checks commented out). IDOR disclosure of audit-step content (REST bodies, field values, assignees, issue keys) for jobs the caller doesn't own is out of scope. getCreateIssuesData returns bulk-create results looked up only by a client "reference", with no caller/owner check, and those references are generated client-side with Math.random() (predictable). IDOR or brute-force disclosure of others' results is out of scope. removeTemplate/removeExecutor/saveTemplate/saveExecutor gate their ownership and permission checks behind a stored app-version check (appVersion >= PERMISSIONS_ACTIVE_VERSION), so on older tenants the checks are skipped while delete/update still runs. Cross-project read/overwrite/deletion (including GLOBAL/-1) is out of scope. importData lacks the Jira-admin check its siblings have and binds uploaded JSON straight onto persistence classes (mass assignment), and the destination projectKey is concatenated unencoded into a Jira REST path. Bulk cross-project template/executor overwrite, internal-field injection, and projectKey path manipulation are out of scope. createExamples loads examples1.properties by a CWD-relative path and substitutes unescaped user values into JSON before Gson parsing (JSON injection / mass assignment); convertTmToStm uses a hard-coded AES-CBC key (no integrity) and merges the decrypted remote response into the tenant's access-control/group config. Both (admin-gated) are out of scope. moveTemplate/moveExecutor authorize the source project but not the destination projectId, letting an admin of one project move objects into another project or GLOBAL. Out of scope. IdentificationToken (sharedSecret, public key, OAuth credentials, Forge token) is serialized to logs at INFO ("IDTOK="), as is full app-properties/group/role config, OAuth-token fragments, full JWTs on failure, full request bodies, and complete header dumps (incl. Authorization/x-forge-oauth-). Secret/PII disclosure to anyone with log access is out of scope. Cron/maintenance endpoints (/cron/purgeOldRecords/..., /cronBackup/backupData/..., backup-service calls) are protected only by a single hard-coded UUID committed to source and shared across purge/backup/workflow-result; the destructive purge also lacks the production guard the others have. Triggering mass deletion, full-tenant backup/export, or workflow-result processing via this token is out of scope. Endpoints loop over user arrays without size caps or length-match validation (deleteIssues, getExecutorForTemplates/getTemplatesForExecutors) and read request bodies without a content-length limit. Resource-exhaustion DoS and the related ArrayIndexOutOfBounds/NullPointerException conditions are out of scope. ProcessTask authenticates only by presence of X-AppEngine-TaskName and trusts the deserialized IdentificationToken without re-resolving the tenant; the static-file/React loader builds resource and Velocity-template paths from the request URI without canonicalization/traversal rejection. Out of scope. The Connect Custom-UI React runs eval() on component/icon names taken from server-stored, user-edited template/executor config (React.createElement(eval(cf.component), ...)), giving stored XSS / arbitrary JS in the rendering user's browser. All variants out of scope. The Connect pages have many XSS/injection sinks: Velocity renders request values (issueId, issueKey, projectId, mode, returnUrl, userId) unescaped into inline and attributes (incl. unquoted monitorForExecutors($issueId) and stored error text in subTaskManagerErrors.vm); jQuery injects server/Jira/issue strings via .html(), unescaped data-* attributes, string-built onclick, attribute-selector concatenation, and .html() round-tripping; server objects are serialized raw into . All resulting reflected/stored XSS, HTML/JS/JSON injection, and Velocity SSTI are out of scope. redirectToBulkRun reflects unencoded query params (mode, issues, link, startIssue) into window.location.replace, and REST/JQL URLs are built without encodeURIComponent. Open-redirect and parameter/JQL injection of this form are out of scope. Licence enforcement and access-control ("access denied") exist only in the React frontends (license.js/accessDenied.js, with a client-influenceable licence override) and are bypassable by calling backend endpoints directly. Any bypass relying on a missing equivalent server-side check is out of scope. Secrets are committed/hard-coded: a GitHub PAT in .ci_settings.xml, an NVD API key in pom.xml, the identifier-token AES key (ECB mode), the conversion-flow AES key, and the cron/backup path UUIDs. Disclosure or use of these is out of scope. Forge triggers forward attacker-influenced webhook payloads (user, issue, comment, changelog) to the backend and convert ADF/wiki to HTML without neutralizing javascript:/data: URIs or stripping /embed-card markup. Acting-user spoofing and stored XSS/clickjacking via the generated HTML are out of scope. Broad-privilege/weak-hardening observations are out of scope: the Connect descriptor requests global ADMIN (plus PROJECT_ADMIN/DELETE); the Forge manifest grants manage:jira-configuration and write:jira-work with wildcard egress (*.appspot.com, *.atlassian.net) and a CSP allowing unsafe-inline/unsafe-eval; the Connect pages set no CSP or frame-ancestors. Known-vulnerable/unmaintained dependencies and tooling are out of scope: react-scripts 5.0.1 (vulnerable nth-check/postcss/webpack-dev-server), crypto-js < 4.2.0 (CVE-2023-46233), mismatched react-router majors, jQuery 3.3.1 from CDN without SRI (CVE-2019-11358), outdated endpoints-framework and OWASP dependency-check, missing JS lockfiles/floating ranges, and a non-profile-gated JDWP debug-agent config. Minor hardening observations are out of scope: endpoints returning raw config maps or full stack traces; Long ==/!= identity comparisons and pre-auth parameter parsing; fail-soft JWT verification with non-thread-safe shared static state; synthetic user attribution on restore/bulk paths; getTemplatesForProject omitting the permission check and trusting the page parameter; decodeForHtml-only handling of template name/description/link; and verbose console logging of tokens/payloads/context. ### Custom Fields Field value access/updates restricted solely by field security, ignoring project/issue view permissions. The internal "vversion" maintenance method and anything reachable through it (unauthenticated state changes, cross-tenant access, or deletion via guessed/known IDs) — being removed. Authorization/access-control inconsistencies in field-value save operations on the Forge API variant (admin allow/deny quirks, project-field vs issue-field permission differences). Stored or reflected HTML/rich-text XSS, including any sanitizer bypass, outdated, or overly permissive sanitizer policy. Findings based solely on a third-party dependency version (sanitizer, test framework, API/endpoints framework, rich-text editor, transitive packages) or raw CVE/scanner output with no working exploit. Unauthenticated page-load/HTML shell endpoints (including React page-load routes) and any reflected-parameter, open-redirect, or framing/clickjacking issue arising from them. REST integration token handling — encryption mode, key management, lack of expiry/rotation, and exposure of an installation's own token to its own authenticated Jira admin. CORS configuration on the API, including permissive origin matching and credentialed CORS responses. Webhook error-handling/logging behaviour, including failed-auth requests processed before rejection and request-body logging. Resource-consumption/DoS against search, backup, bulk, or query operations (large result sets, unbounded queries, in-memory loading, expensive regex), including self-DoS limited to your own tenant. Scheduled-task/cron endpoints (purge, backup) — reports relying on spoofing the App Engine cron-only header or on knowing a published config identifier. SSRF where the outbound destination derives from the platform-provided request URL or the installation's own verified base URL (no attacker-controlled host). Missing or weak HTTP security response headers (CSP, X-Content-Type-Options, X-Frame-Options) and missing Content-Type on static assets, absent a demonstrated exploit. Static-asset/resource path handling (normalization, missing-file handling) where impact is limited to packaged content or a non-exploitable error response. Verbose application logging of tokens, identifiers, claim sets, or request bodies. Mass-assignment/input-trust on the field, validator, saved-search, and configuration write APIs where access stays correctly scoped to the authenticated tenant. The identity/context ("identifier") auth mechanism and any weakness in it — client-side/symmetric encryption of identity data, secrets in the JS bundle, and the backend trusting a client-supplied identity value, including forging/replaying/tampering it to assert another identity, tenant, project, or entitlement and any resulting cross-tenant read/write/delete. Client-side license/entitlement enforcement (bypassing a "not licensed" screen, build-time overrides, asserting an active license to the backend); unlicensed use is a licensing matter, not a vulnerability. Exposure of an installation's own REST/integration token to its own authenticated admin (shown on the admin config screen, held in client state, or copied by the owning admin). The app's CSP and iframe content settings (inline scripts/styles or eval in its own UI) and any DOM-based finding depending on them, absent a concrete cross-user exploit. The breadth of declared egress/permission allowlists or requested product scopes (wildcard fetch domains, seemingly broad scopes), absent a demonstrated exploit. Client-side encoding of identifiers in API paths/query strings and parameter/path handling on calls to the app's own backend, where no cross-tenant or privilege-boundary impact is shown. Client-side info exposure/config observations — debug/console logging, third-party UI-component license keys in the bundle, i18n/translation handling — absent a concrete exploit. ### Watch It Email contents. Hardcoded outbound API keys; unauthenticated legacy vversion/admin endpoints; weak static crypto; Forge header trust without signature verification; dashboard HTML injection; token material in logs; client-controlled Jira URL fetch surface. Any forging, tampering, decryption, or replay of the client-supplied identity / authorization payload (the "sender" / "identifier" / "currentPage" value and the accompanying "contextlicense" value) that the front-end builds from page, projectId, issueId, licenseActive, cloudId, accountId, siteUrl and timestamp, including any impersonation of another account, project, tenant/cloudId, or license state achieved through it. Known and tracked. Forging, tampering, decrypting, or replaying the client-supplied identity/authorization payload (the "sender"/"identifier"/"currentPage" and "contextlicense" values built from page, projectId, issueId, licenseActive, cloudId, accountId, siteUrl, timestamp), including impersonating another account, project, tenant/cloudId, or license state. Recovering or using the symmetric key embedded in the shipped bundles and source maps that protects the client identity payload, and any weakness in its cipher mode, hash-derived key, or missing IV/MAC/integrity/replay protection. Backend trust of client-supplied identity, tenant, project, or license selectors passed as parameters or headers (projectId, cloudId, clientKey, accountId, identifier, sender, contextlicense, X-Cloud-Id, X-Forge-Cloud-Id, X-Forge-Source, X-Forge-Timer, X-Watch-It-Source, X-Forge-Installation-Id) for routing, identity, tenant selection, or authorization instead of a server-verified token. Unauthenticated submission of forged Forge webhook or issue-update events to the Connect ingress (e.g. /forgeWebhook, /issueUpdated) accepted on request markers/headers rather than a verified Forge app token, including selecting the target tenant via a header to generate notifications/emails or inject content for any tenant. Overwriting, poisoning, or denial-of-service of a tenant's stored OAuth/credential material via header-gated ingress paths (e.g. updateOAuthToken, registerCloudId). Any servlet, filter, or code path that skips or weakens JWT/token validation based on the presence or value of a request header (e.g. a "forge source" or "watch-it source" marker). Using the static per-tenant REST bearer token ("RESTAuthToken") to read, create, modify, enumerate, or delete watcher data across projects, including the token carrying no per-user/role/project scope, being returned to or settable from the browser, or being compared in non-constant time. Invoking maintenance, version, statistics, delete-account, or config-migration operations gated only by a hardcoded identifier (magic GUID/string) and/or a fixed query flag rather than an authenticated authorized session, including destructive cross-tenant deletion, cross-install config rewriting, or aggregate/global statistics disclosure. Discovering the static identifiers, magic GUIDs, or query flags that gate maintenance/administrative operations from source, front-end bundles, source maps, backup files, or decompiled artifacts. Missing, incorrect, inverted, or skipped per-user/role/project authorization on tenant-scoped Connect or Forge endpoints (project config, watchers, timed watchers, watcher rules, access-permission settings, audit/notification history, exports, page loads), including a non-admin or wrong-project user reading or modifying another project's data or webhook configuration. Insecure direct object references where an object id (watcher id, audit/notification id, etc.) is not verified to belong to the project/context in the request, exposing another project's or watcher's data, history, recipients, or message bodies. Reassignment or mass-assignment of fields the caller should not control (e.g. a watcher or rule "owner") via client-supplied values on create/update. Confused-deputy access where server-side or Forge resolver code makes Jira API calls with the app's own elevated credentials based on a client-supplied project id without verifying the caller's access (e.g. create-metadata, fields). Abuse of the attachment/image proxy servlet authorized only by an HMAC whose signing key is hardcoded in source, including forging signed URLs, retrieving another tenant's attachments/resources via stored credentials, reaching non-attachment paths via lax path validation, cross-tenant replay, or timing attacks on the signature comparison. Server-side request forgery via outbound requests whose destination is taken from stored or admin-configured data (notably timed-watcher webhook targets) without an egress allow-list or protection against internal, link-local, or cloud-metadata ranges. Stored or reflected XSS / HTML injection in notification emails from Jira issue-derived fields (summary, status, assignee/display names, description) rendered without consistent output encoding, including paths that decode previously escaped markup back into live HTML. Stored or reflected XSS in the Forge dashboard/notification gadget from Jira change data rendered as raw HTML (dangerouslySetInnerHTML/innerHTML), including XSS relying on the HTML sanitizer being bypassed, out of date, or too permissive. HTML/content injection from the wiki-markup/ADF-to-HTML conversion in Forge triggers that fails to consistently escape interpolated text/attributes, enforce a URL-scheme allow-list on links/images, or suppress frames from card nodes (dangerous schemes, attribute breakout, tracking pixels, embedded iframes). Injection into stored configuration or watcher conditions from user-controlled values (e.g. component/field value id and name) concatenated into stored JSON or condition strings without proper encoding. Breakout from an inline-script or HTML context via server-rendered configuration- or translation-derived strings (e.g. event-type labels) emitted without context-appropriate encoding. Recovering or using secrets in the source tree, version-control history, backup/".backup"/".bak" files, compiled jars, browser bundles, or source maps, including the client-identity encryption key, the attachment-proxy HMAC signing key, and the third-party email-API key. Information disclosure via verbose error messages or stack traces returned to clients, or logging of sensitive data (full config/property maps, tokens, decrypted authentication material, OAuth token fragments, full issue/notification content, or JWTs in the browser console). Disclosure of backend hostnames/endpoints (including non-production hosts), customer-specific conditionals, third-party integration ids, or other implementation/topology detail present in shipped front-end source, HTML templates, or source maps. License, entitlement, or paywall bypass via client-side license logic, host-name-based license overrides, or the forwarded license flag, where licensing is not yet enforced server-side. Findings that the Forge manifest egress allow-list (including wildcard cloud domains), granted scopes (including unused elevated scopes), or content-security policy (including inline/eval script) are broader than strictly necessary. Third-party script inclusion in application iframes without subresource integrity (e.g. analytics/changelog widgets such as Beamer) or related supply-chain exposure of these embedded widgets. Outdated or vulnerable dependency versions, npm-audit output, or dependency CVEs (e.g. react-scripts and its transitive chain, crypto-js below 4.2.0, dated i18n libraries) without a demonstrated novel, application-specific exploit not already covered here. Timing-oracle or non-constant-time comparison findings against secret, token, or signature comparisons. Internal cron, task-queue, or scheduled-trigger endpoints that rely on platform-provided headers (e.g. App Engine cron/task headers) and/or static in-source path tokens for trust.+ Document Vault: Broken Access Control / IDOR — reading or deleting attachments and comments belonging to Jira issues you do not have access to (root cause: prefix-match issue scoping). ### Document Vault updateFile lacks issueId validation; uploads allow cross-issue files; create issue lacks project validation; resolvers (deleteAttachment, updateFile, saveComment, setStorage, getStorage, deleteStorage, setKeyValue, getKeyValue, runApiCall) lack access control; runApiCall allows arbitrary Jira APIs; get tokens leaks tokens; emails open to HTML injection. Sensitive Data Exposure — Jira/Atlassian OAuth access tokens exposed to or recoverable by the browser front-end, including any client-side "encryption" whose key is also shipped to the client. Sensitive Data Exposure — Jira/Forge OAuth access tokens transmitted to or returned by the external token/upload service, including a raw Bearer token disclosed during the upload-session redeem flow. Sensitive Data Exposure — hardcoded secret/cryptographic key recoverable from the client bundle or app artifact, reused for token encryption, payload decryption, and service authentication. Broken/Weak Cryptography — app-layer payload and token protection uses AES-CBC, MD5-based key derivation, and no integrity/AEAD (malleability, padding-oracle, MD5). Broken Cryptography / Security-Through-Obscurity — reversible client↔server payload "encryption" using an empty or publicly-known key; provides no confidentiality. Use of Hardcoded/Default Cryptographic Material — fallback development RSA key and default service endpoint URLs used when configuration is absent. Broken Authentication — forgeable service-to-service auth on the internal upload endpoint (HMAC secret defaults to a known value), and replay of internal upload actions. Stored / DOM-based XSS — rendering of user-supplied comment/markup content as HTML. Unrestricted File Upload — files accepted with extension-only validation, no MIME/magic-byte verification, and no size limit. Security Misconfiguration — weak Content Security Policy (unsafe-inline / unsafe-eval for scripts and styles). Security Misconfiguration — over-broad outbound network (fetch) allowlist using wildcard domains, and excessive requested OAuth scopes. Lack of Rate Limiting / Anti-Automation — no throttling on web-trigger endpoints, including a credential-validation oracle on the API-token auth path. Information Disclosure — verbose error messages or stack traces returned to clients. IDOR Enabler — predictable/enumerable storage record identifiers. Improper Input Parsing — fragile hand-rolled multipart/form-data and query-string parsing (parser confusion / value truncation). Vulnerable/Outdated Dependencies — known-vulnerable third-party packages and bundled vendor assets (e.g. bundled TinyMCE). Broken Access Control getGroupMembers, getProjectRoleDetail, and downloadSecuredAttachment perform no Document Vault access-level check, letting any user with a valid session enumerate group/project-role membership or download issue attachments via the app's own elevated Jira token regardless of configured access. write endpoints trust client-supplied author fields (e.g. commentCreatedAuthor, fileUpdatedAuthor) without validating them against the authenticated caller, allowing forged authorship. sendEmailNotification does not restrict which Jira groups may be targeted, letting any full-access user send app-originated email to arbitrary sitewide groups. Injection — unescaped values are concatenated into Jira REST API URLs (issueKey on upload endpoints) and into JQL queries built by the admin migration importer. Broken/Weak Cryptography — non-constant-time comparison of the upload-session nonce during session redemption. Insecure Client-Side Storage — unencrypted migrated attachment/comment content is cached in browser localStorage/IndexedDB during the admin migration flow. The following finding types are specifically excluded from the bounty The use of Automated scanners is strictly prohibited (we have these tools too - don't even think about using them) Descriptive error messages (e.g. Stack Traces, application or server errors). Fingerprinting / banner disclosure on common/public services. Clickjacking and issues only exploitable through clickjacking. Logout Cross-Site Request Forgery (logout CSRF). Content Spoofing. Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality. Lack of Secure/HTTPOnly flags on non-sensitive Cookies. Lack of Security Speedbump when leaving the site. Weak Captcha / Captcha Bypass. Login or Forgot Password page brute force and account lockout not enforced. Username / email enumeration. Missing HTTP security headers, specifically ( https://owasp.org/www-project-secure-headers/ ), e.g. Strict-Transport-Security. X-Frame-Options. X-XSS-Protection. X-Content-Type-Options. Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP. Content-Security-Policy-Report-Only. Cache-Control and Pragma HTTP/DNS cache poisoning. SSL/TLS Issues, e.g. SSL Attacks such as BEAST, BREACH, Renegotiation attack. SSL Forward secrecy not enabled. SSL weak/insecure cipher suites. Self-XSS reports will not be accepted. Similarly, any XSS where local access is required (i.e. User-Agent Header injection) will not be accepted. The only exception will be if you can show a working off-path MiTM attack that will allow for the XSS to trigger. Vulnerabilities that are limited to unsupported browsers will not be accepted (i.e. "this exploit only works in IE6/IE7"). A list of supported browsers can be found here . Known vulnerabilities in used libraries, or the reports that an Atlassian product uses an outdated third party library (e.g. jQuery, Apache HttpComponents etc) unless you can prove exploitability. Missing or incorrect SPF records of any kind. Missing or incorrect DMARC records of any kind. Source code disclosure vulnerabilities. Information disclosure of non-confidential information (e. g. issue id, project id, commit hashes). The ability to upload/download viruses or malicious files to the platform. Email bombing/Flooding/rate limiting. Rules Data & Instances: Test only on your own instances. Do not affect, access, or use credentials for customer data/instances. Vulnerabilities: If you find sensitive customer data or an access vulnerability, report it immediately; do not attempt to validate or test it. Prohibited Testing: * No automated tools/scanners (violators will be banned). No social engineering, phishing, or unauthorized infrastructure access. No physical security testing of offices, employees, or equipment. Reporting: Submit in plain text only (standard image/video formats are allowed). PDFs or DOCX files will require resubmission. Payouts: Redmoon Software fairly determines all grants/awards at its discretion. Reporters are solely responsible for any associated tax implications. Disclosure: Follows Bugcrowd’s standard disclosure terms. Public Disclosure You must request permission before publicly disclosing any issue. Publicly disclosing without written consent will result in bounty withdrawal and program disqualification. Safe Harbor Vulnerability research conducted under this policy is considered: Authorized: Under the CFAA (and state laws); we won't pursue legal action for accidental, good-faith violations. DMCA Exempt: We won't bring claims for circumventing technological controls. Terms Exempt: Relevant restrictions in our Terms & Conditions are waived on a limited basis. Lawful & Helpful: Recognized as good-faith contributions to internet security. You must still comply with all applicable laws. If uncertain whether your research aligns with this policy, submit a report through an Official Channel before proceeding.