We’re Tracking the Future of Security

Category: Cyber-Physical Security

Coverage of the convergence between IT/cybersecurity and physical security systems, including networked device risk, secure system integration and unified threat response.

  • CISA Flags Exploited SharePoint and MikroTik RouterOS Vulnerabilities

    CISA Flags Exploited SharePoint and MikroTik RouterOS Vulnerabilities

    The U.S. Cybersecurity and Infrastructure Security Agency has added vulnerabilities affecting Microsoft SharePoint and MikroTik RouterOS to its Known Exploited Vulnerabilities catalog. The catalog records confirmed exploitation and directs U.S. federal civilian agencies to apply vendor mitigations by September 28, 2026.

    The entries affect different layers of infrastructure

    CVE-2026-65660 is a SharePoint code-injection vulnerability that Microsoft describes as allowing an authorized attacker to execute code over a network. CVE-2026-67279 affects RouterOS workflow enforcement and can allow an unauthenticated client to open a session channel and send an execution request. CISA notes that the RouterOS weakness can be chained with CVE-2026-86060 for unauthenticated exploitation.

    The two entries should not be treated as a single technical flaw. One concerns collaboration-server code execution, while the other is part of a router attack chain. Their shared significance is operational: both are now associated with observed exploitation rather than theoretical risk alone.

    Inventory and exposure determine priority

    Defenders should identify affected SharePoint and RouterOS assets, confirm internet exposure, apply vendor guidance and preserve evidence where compromise is suspected. Unsupported or unmitigated systems may require isolation or retirement. Monitoring should continue after patching because remediation does not remove persistence established before the update. SectechMedia follows related operational risks in its cyber-physical security channel.

    Sources

  • Elementor CSRF Flaw Could Turn an Administrator Click Into Site Takeover

    Elementor CSRF Flaw Could Turn an Administrator Click Into Site Takeover

    Security researchers have disclosed a high-severity cross-site request forgery flaw in Elementor Website Builder versions 4.3.0 and 4.3.1. The weakness could allow a crafted link opened by a logged-in WordPress administrator to perform REST API actions with that administrator’s permissions, including creating another privileged account on a default installation.

    The flaw extended beyond one Elementor route

    Patchstack traced the issue to the Editor Events module, which exempted requests from WordPress nonce checks when a particular Elementor route string appeared anywhere in the request URI. Because an attacker could place that string in a query parameter, the exemption could affect other WordPress core or plugin REST routes. The attack did not require a malicious page or JavaScript; the trigger could be an ordinary link delivered through email, chat or a comment.

    The affected module is present only in the two identified releases. Patchstack says the issue was addressed in Elementor 4.3.2 following responsible disclosure. Administrators should verify the installed version and update through their normal change-control process.

    Session context remains a critical control

    The attack depends on a privileged user being authenticated when the link is opened. Organizations can reduce exposure through rapid patching, limited administrator accounts, separate browsing practices and review of newly created users. Security teams should also inspect audit logs for unexpected REST activity. SectechMedia tracks related risks in its cyber-physical security coverage.

    Sources

  • Video Retention Capacity Testing Under Variable Bitrate Conditions

    Video Retention Capacity Testing Under Variable Bitrate Conditions

    A storage calculation based on one nominal bitrate can produce a false sense of retention. Video consumption changes with motion, lighting, noise, compression settings, scene complexity and analytics metadata. Acceptance testing should demonstrate actual retention under representative conditions and confirm what happens when capacity or a recorder node is lost.

    Establish the required retention outcome

    Define retention by camera class and recording mode. Continuous recording, motion recording and event recording create different evidence profiles. State whether the requirement is a minimum number of complete days, a calendar rule or a combination with protected incident clips.

    Inventory resolution, frame rate, codec, quality, audio and secondary streams. Verify that the configuration in the recorder matches the approved design. A camera may send a higher frame rate or different codec after replacement, increasing storage without an obvious alarm.

    Measure real bitrate variation

    Collect bitrate and storage data across representative periods. Busy entrances, rain, foliage, low-light noise and changing illumination can increase encoded data. A quiet overnight sample should not be used to predict a crowded daytime scene. Include weekends, events and seasonal conditions where they materially change activity.

    Use percentiles and peak observations as well as averages. The design needs headroom for bursts, database growth, indexes and system overhead. Deduplication or compression claims should be validated on the deployed workload rather than transferred from a laboratory example.

    Test failover and degraded capacity

    Remove a storage path or recorder node using an approved test method. Confirm whether recording continues, which cameras are affected and whether operators receive a clear health alarm. When service returns, verify synchronization and identify any gap rather than assuming the platform reconstructed missing footage.

    Check protected clips, legal holds and export staging areas because they may consume space outside the normal retention model. A surge in retained incidents can shorten ordinary footage if the system does not reserve capacity or report the change.

    Validate deletion and evidence recovery

    Observe the oldest available recording for each camera class over time. Confirm that automatic deletion follows policy and that manual exports do not alter source footage. Test retrieval near the retention boundary, including playback, audit records and checksum or metadata features supported by the platform.

    Document the baseline, measured daily growth, free capacity, assumptions and alert thresholds. Review it after camera additions, firmware changes, codec updates or scene changes. Storage assurance is central to Video Surveillance & Imaging: a camera can appear healthy while required evidence has already been overwritten.

    Capacity dashboards should be reviewed against observed footage, not accepted as the sole evidence. Assign ownership for investigating sudden bitrate or retention changes and preserve the configuration that produced the accepted result. A monthly trend can reveal gradual loss of headroom before the system breaches its minimum retention obligation.

    Reference sources

  • Video Surveillance Time Synchronization and Evidence Timeline Validation

    Video Surveillance Time Synchronization and Evidence Timeline Validation

    Video evidence is often compared with access-control events, alarms, radio calls and witness accounts. If those systems use different clocks, an apparently precise timestamp can create a misleading sequence. Time synchronization acceptance should therefore test the complete path from camera to recorder, export file and operator display.

    Define the authoritative time source

    Document which service provides authoritative time, how devices reach it and what happens when the service is unavailable. Cameras, recorders, analytics servers and management workstations may each maintain a local clock. A system can show the correct time on one screen while embedded video metadata or exported filenames remain offset.

    Record time zone, daylight-saving behavior and whether interfaces display local time or UTC. Mixed conventions are especially risky during seasonal clock changes. The design should avoid manual adjustments that create discontinuities or duplicate local times in recorded evidence.

    Measure offset across the full system

    Compare each device with a controlled reference and record the observed offset. Test representative cameras on different networks, recorder nodes and failover paths. The acceptable tolerance should come from the operational use case: a general observation system may tolerate more offset than a workflow that correlates a door transaction with a person crossing a camera view.

    Do not stop at the live view. Review recorded playback, analytics events, bookmarks, exports and audit logs. Some platforms write one timestamp into media metadata and another into an application database. Confirm that an exported clip preserves enough information to interpret the displayed time correctly.

    Test outages and recovery

    Temporarily remove access to the approved time source using a controlled test. Observe whether devices free-run, raise a health alarm or switch to an unauthorized source. After service is restored, verify how clocks are corrected. A sudden backward step can affect recording indexes, event order and retention calculations.

    Network controls should permit time traffic only to approved services and monitor repeated failures. Authentication should be used where the architecture supports it. Time synchronization is not only an availability function; an attacker who can influence clocks may complicate investigation and conceal the relationship between events.

    Preserve a repeatable evidence baseline

    The acceptance record should list device identifiers, firmware, time source, configuration, measured offset and test date. Include screenshots or exported metadata from a controlled event visible to multiple systems. Repeat the check after recorder replacement, network redesign, firmware upgrades or unexplained timeline discrepancies.

    Time assurance belongs with broader Video Surveillance & Imaging governance. A synchronized display is useful, but a defensible incident timeline requires proof that capture, storage, event correlation and export all interpret time consistently.

    Assign an owner for reviewing synchronization health and define a threshold that triggers investigation. Monitoring should distinguish an unreachable time source from a device that remains reachable but drifts. Periodic controlled events visible in video and another trusted system provide a practical end-to-end check between formal acceptance tests.

    Reference sources

  • PamStealer macOS Malware Adds Live Decryption and Multi-Layer Persistence

    PamStealer macOS Malware Adds Live Decryption and Multi-Layer Persistence

    Jamf Threat Labs has documented a new PamStealer macOS campaign that changes how the main payload is recovered and persisted. The operation uses a bogus cryptocurrency-wallet site and an AppleScript-based lure, while payload decryption depends on communication with attacker-controlled infrastructure.

    Server-assisted decryption limits static recovery

    Earlier variants embedded more of the decryption material in the initial script. Jamf reported that the newer Wavel-themed chain downloads a purpose-built utility and completes a key exchange before the payload can be unpacked. Without the server’s cooperation, analysts cannot recover the final component from the first-stage file alone.

    The victim is directed to open a disk image and run an AppleScript through Script Editor. A JavaScript for Automation carrier then hands execution to a shell process. The campaign relies on user action and abuse of trusted operating-system tools rather than a single remote exploitation step.

    Persistence and credential exposure widen the impact

    The reported chain installs multiple persistence mechanisms and seeks browser, wallet and account information. Defenders should preserve the initial lure, process tree, downloaded utilities and network destinations because any one layer may disappear after infrastructure changes.

    Endpoint monitoring should flag unusual Script Editor-to-shell execution, new launch items and unsigned utilities retrieved from recently registered infrastructure. These controls complement the identity and endpoint concerns covered under Cyber-Physical Security. Users should install software only from verified vendor channels and avoid executing scripts presented by download pages.

    Sources

  • Compromised GitHub Actions Resume Mini Shai-Hulud Malware Execution

    Compromised GitHub Actions Resume Mini Shai-Hulud Malware Execution

    Two GitHub Actions previously compromised during the Mini Shai-Hulud campaign became accessible again in September while release tags still pointed to malicious content, according to research from Socket. GitHub has since disabled the affected repositories again.

    Availability reactivated an existing dependency risk

    The affected actions, actions-cool/issues-helper and actions-cool/maintain-one-comment, had been disabled after malicious code was introduced in May. Socket reported that the repositories returned on September 16 without the compromised release tags being cleaned. Workflows referencing those mutable tags could therefore download and execute the old payload even though no new malicious version was published.

    The payload was associated with credential theft from CI/CD environments. The event illustrates why containment cannot rely only on making a repository unavailable: tags, releases and downstream references must also be reviewed before access is restored.

    Consumers need immutable references and recovery checks

    Development teams should locate references to the affected actions, rotate exposed secrets and inspect workflow history after the repositories reappeared. Pinning third-party actions to reviewed commit hashes reduces dependence on mutable upstream tags, although the selected commit still needs security review.

    The incident extends the risk described in SectechMedia’s Cyber-Physical Security coverage. Organizations should inventory external workflow components, monitor ownership and availability changes, and treat repository restoration as a security-sensitive event rather than a purely operational one.

    Sources

  • Bitget Reports $351.6 Million Theft After Wallet Backend Compromise

    Bitget Reports $351.6 Million Theft After Wallet Backend Compromise

    Cryptocurrency exchange Bitget says attackers stole $351.6 million from a limited set of hot and warm wallets after compromising a critical backend system in its wallet infrastructure. The company detected unauthorized transfers on September 24 and temporarily suspended withdrawals while it investigated.

    What Bitget has disclosed

    Bitget said its cold wallets and most platform assets were not affected, and that customer account balances remained recorded correctly. According to the company, the attacker manipulated transaction data and triggered the authorization process to move funds. Bitget engaged Mandiant and SlowMist for outside investigation and contacted affected blockchain foundations about freezing addresses.

    The company attributed the activity pattern to suspected North Korean actors, but that attribution remains an assessment rather than an independently confirmed finding. The intrusion method also remains under investigation. Reporting should therefore separate confirmed unauthorized transfers and the disclosed backend compromise from still-developing attribution details.

    Security implications

    The incident highlights the need to isolate signing systems, require independent transaction verification, limit hot-wallet balances and test controls against compromised backend data. Exchanges also need rehearsed withdrawal suspension, chain-monitoring and customer-communication procedures. SectechMedia tracks connected risks in its cyber-physical security channel.

    Sources

  • CISA Adds Exploited WSO2 and Adobe Commerce Flaws to KEV Catalog

    CISA Adds Exploited WSO2 and Adobe Commerce Flaws to KEV Catalog

    The U.S. Cybersecurity and Infrastructure Security Agency has added two enterprise-software vulnerabilities to its Known Exploited Vulnerabilities catalog. The additions cover CVE-2026-5430 in WSO2 products and CVE-2026-71362 in Adobe Commerce and Magento.

    Two different attack paths

    The WSO2 issue is a path-traversal weakness that can enable unrestricted file upload and potentially remote code execution in affected API-management components. Security researchers reported exploitation attempts before the catalog update. The Adobe Commerce issue is an authorization flaw that can allow an attacker to reach another customer’s account context and sensitive information under vulnerable conditions.

    KEV inclusion means CISA has evidence that the vulnerabilities are being exploited, not merely that public proof-of-concept material exists. Federal civilian agencies received a remediation deadline, while private organizations can use the catalog as a prioritization signal alongside asset exposure, business impact and compensating controls.

    Prioritization for defenders

    Teams should inventory affected WSO2, Adobe Commerce and Magento deployments, compare versions against vendor advisories, apply fixes, and inspect logs for file-upload anomalies, forged tokens or unusual account switching. Internet-facing systems and identity-connected APIs deserve immediate attention. SectechMedia follows similar operational risk in its cyber-physical security channel.

    Sources

  • Cloudflare Fixes Cross-Tenant Disk Data Exposure in Container Platform

    Cloudflare Fixes Cross-Tenant Disk Data Exposure in Container Platform

    Cloudflare has disclosed and fixed a cross-tenant data exposure issue affecting its Containers and Sandboxes products. The flaw involved storage reuse: a newly provisioned workload could receive disk blocks that still contained residual data from a previous customer.

    How the isolation failure occurred

    Researchers at Accomplish demonstrated that discarded thin-provisioned storage was not reliably cleared before reuse. That created a path for one tenant to inspect fragments left by another. Cloudflare said the affected products were in beta and reported no evidence that the issue had been exploited maliciously.

    The company disabled the relevant storage behavior, introduced sanitization controls and reviewed the platform after receiving the report. Cloudflare’s account and the researchers’ technical write-up agree on the core risk, although they describe some affected service details differently. The incident illustrates that workload isolation depends on storage lifecycle controls as well as compute and network boundaries.

    Lessons for multi-tenant platforms

    Operators should include block-device reuse, snapshot handling and deprovisioning in tenant-isolation tests. Encryption, secure erase procedures and monitoring for unexpected reads can add defense in depth, but each control must be verified against the actual storage architecture. Customers should also avoid treating beta isolation guarantees as equivalent to mature production assurance. Related coverage appears in SectechMedia’s cyber-physical security channel.

    Sources

  • Roundcube Pre-Authentication SQL Injection Is Under Active Exploitation

    Roundcube Pre-Authentication SQL Injection Is Under Active Exploitation

    Canada’s Cyber Centre has warned that attackers are actively exploiting a patched Roundcube Webmail vulnerability. Tracked as CVE-2026-48842, the flaw affects the virtuser_query plugin and can permit SQL injection before a user authenticates.

    What the advisory confirms

    Roundcube released fixes in versions 1.6.16 and 1.7.1 on May 24. The project described the issue as a security defect involving query handling, while the Canadian advisory now adds evidence of exploitation in the wild. The available notices do not disclose a detailed campaign profile, so attribution and victim counts remain unconfirmed.

    The risk depends on whether the vulnerable plugin is enabled and how the database is configured. Successful injection could expose information held by the webmail backend, including data that may support further account compromise. Internet-facing email systems are especially sensitive because they combine identity, communications and recovery workflows.

    Immediate defensive actions

    Administrators should identify Roundcube versions and enabled plugins, upgrade to a fixed release, review web and database logs for unusual query patterns, and rotate affected credentials if compromise is suspected. Restricting unnecessary public exposure and applying least privilege to the database account can reduce impact. SectechMedia covers connected defensive controls in its cyber-physical security channel.

    Sources