Vulnerability research across MiPOS Digital: first results

This article presents the first complete cycle of vulnerability research across MiPOS Digital: authorized scope, method, quantified results, remediation priorities, and retest criteria. It applies the approach documented in Vulnerability research across six first-party SaaS products and the protocol in Security patch validation: from finding to closure.

The assessment confirmed 28 findings with reproduction evidence. Five were classified as Critical, three as High, seven as Medium, ten as Low, and three as Informational. This publication is not an attack guide: secret values, requests, responses, internal identifiers, and proofs of concept remain in private evidence. What we make public is the verifiable outcome, how it was classified, and the standard we will use to close each risk.

Authorized scope and controlled environment

MiPOS Digital is a product built and operated by Cloudsoft Industries. This cycle was therefore explicitly authorized first-party research limited to systems we own. The evaluated system combines a .NET backend and a React frontend. Testing used the source code and a live Dockerized instance with an isolated database and no contact with production.

The technical scope included:

• the REST API and its authentication and authorization controls;
• tenant-isolation boundaries and object- and function-level permissions;
• Alegra integration webhooks treated as an inbound trust boundary;
• configuration, secret handling, and third-party dependencies;
• frontend packages managed through NPM and .NET dependencies managed through NuGet.

No third-party systems or client environments were tested. Integrations were assessed through MiPOS Digital's behavior and inside the controlled environment. This boundary matters: defensible security testing requires written authorization, identified assets, isolated data, and stop conditions before testing begins.

Method applied

The cycle followed Cloudsoft Industries' published six-step method. Assisted testing expanded coverage, but no result was counted as confirmed without reproducible evidence and technical impact review.

1. Inventory and trust model. We recorded assets, roles, integrations, sensitive data, and boundaries between organizations.
2. Abuse hypotheses. We turned each boundary into a testable question about authentication, authorization, isolation, integrity, or availability.
3. Manual and assisted testing. We combined code and configuration review with bounded, automation-assisted dynamic testing. Every result still required technical validation.
4. Minimal reproduction. We retained preconditions, request, response, affected version, and impact. Sensitive proof remains private.
5. Classification and priority. We combined technical severity with product context to decide what required remediation first.
6. Remediation and retest. We defined the expected secure result and the negative test that must demonstrate it after the change.

Coverage was cross-checked against the OWASP API Security Top 10 2023, OWASP ASVS 5.0.0, and the planning and reporting practices in NIST SP 800-115. We used FIRST CVSS v4.0 to communicate severity alongside context such as privileges, cross-tenant reach, and recoverability.

Confirmed results

The 28 findings fell into three families. The table preserves quantitative traceability without publishing details that could facilitate exploitation while remediation remains open.

Category	Findings	Remediation priority
Secrets in source code	6	Immediate rotation, invalidation, and repository cleanup
Access control and tenant isolation	7	Corrections prioritized in the second phase
Dependencies with known CVEs	15	Upgrades and CI controls planned for the sprint

Secrets and credentials

All five Critical findings involved keys or credentials with production impact stored in plaintext source or configuration. The category covered cloud services, session signing, integrations, transactional email, and databases. A sixth group of secrets was rated High. Publishing file names, values, precise history, or usage instructions would not improve transparency; it would increase risk. That evidence remains private for rotation, invalidation, and retesting.

Access control and isolation

Seven weaknesses related to authorization, authentication, or trust boundaries were confirmed. The set included tenant-isolation conditions, excessive exposure of identity data, an inbound integration without sufficient verification, and administrative or attempt-limiting controls that required strengthening. Several conditions demonstrated cross-organization reach inside the isolated environment, but not every finding belonged to that subcategory. We report the group precisely rather than present all seven cases as equivalent.

Vulnerable dependencies

Fifteen findings involved NPM or NuGet dependencies with a public CVE and an identified upgrade path. The presence of a CVE does not by itself prove that every variant is exploitable in the product. We therefore distinguish the dependency risk, how MiPOS Digital uses it, and validation after the upgrade. The plan includes automated dependency checks in CI so relevant vulnerabilities cannot return without an explicit decision.

Severity distribution and evidence

Severity	Count	Evidence threshold
Critical	5	Confirmed material impact requiring immediate action
High	3	Significant exposure with reproduction
Medium	7	Reproducible condition with bounded or context-dependent impact
Low	10	Limited risk or additional preconditions required
Informational	3	Hardening or exposure requiring follow-up

“Confirmed” means a recorded reproduction exists; it does not mean the proof of concept should be public. The private case file retains the identifier, version, preconditions, redacted evidence, impact, recommendation, and remediation owner. This separation lets another engineer audit the finding without turning the public paper into an operational manual.

Closure and retest

Findings remain open until their closure criteria are met. For secrets, closure requires credential rotation, proof that the previous value no longer works, and assurance that an accessible copy cannot remain usable. For access-control findings, we will repeat the original request as a negative test: the correct server-side control must reject the operation rather than merely hide it in the interface. For dependencies, we will verify the effective version in the deployed artifact and run regression tests on the consuming flows.

Retesting is planned after the corresponding remediation phases. Each outcome will be recorded as Fixed, Partially fixed, Not reproducible, or Risk accepted, with evidence and an accountable owner. A merged commit or closed ticket is not sufficient to declare a vulnerability resolved.

What this publication demonstrates

This article provides public evidence of recent security work under the Cloudsoft Industries name: an identified first-party product, explicit authorization, defined surfaces, a published method, reproducible results, severity, a remediation plan, and retest criteria. It can support a track-record assessment for security research or verification programs, but it does not guarantee eligibility, access, or accreditation. Each program retains its own criteria and independently evaluates the evidence.

This is not a CVE advisory and does not claim credit for a public vulnerability. The findings were identified in a first-party product and are being managed through responsible disclosure while remediation remains open. Teams that need the same approach applied to an authorized development can review our application security, compliance, and penetration-testing service.