A patched flaw just got a wider audience
SAP has added an Operational Data Provisioning security check to SAP EarlyWatch Alert, and it appears only when ODP activity is detected. The defect behind it was fixed months ago. SAP Security Note 3748819, titled 'Missing caller identification check-in for ODP Data Replication APIs', went out in SAP's June 2026 patch day with Medium priority and a CVSS score of 6.6, tracked as CVE-2026-44754.
What changed is distribution. A security note sits in a patch queue that a Basis team triages against everything else in the same window, and a Medium competes badly there. An EarlyWatch Alert finding lands in a weekly report that service delivery managers, application owners and often someone from IT leadership already read. Same defect, different readership.
If your estate extracts data out of ECC or BW over ODP-RFC, expect the question soon, and expect it from someone who has never asked you about a security note before. Our security coverage keeps meeting the same shape, where the fix is old and the attention is new.
What the note actually describes
The problem is a missing authorization check in the RFC modules of the SAP ODP Data Replication API. Those modules were meant to be reachable only by permitted SAP-internal applications, and they were not verifying who was calling. A customer-built or third-party application could call them directly and read data it had no business reading.
SAP rates the note Medium, and the published scoring puts exploitation behind high privileges, so an anonymous caller from the internet is not the threat model. We would still rank it above an average Medium because of where the interface sits. Anything reachable through ODP can see what the extractor can see, which in a BW or ECC system is a lot of business data.
Component names are given here in readable form, with spaces standing in for the punctuation SAP uses in the real identifiers. The affected components are DW4CORE 200, 300 and 400; PI BASIS 2006 1 700, 701, 702, 731 and 740; and SAP BW 750 and 816.
The exposed population is larger than it looks
The organisations that should care are the ones extracting SAP data over ODP-RFC into a platform outside SAP. That is an extremely common shape for anyone feeding a warehouse or lakehouse from SAP source systems, whether the target is a Microsoft stack, a Databricks or Snowflake environment, or something built in-house.
Most of those pipelines are old. The person who set up the RFC destination and picked the service user has usually moved on, the connection has run without complaint for years, and nobody has opened it since the last upgrade. That is why the finding is useful even when the patch is months old. It names an interface nobody currently owns.
If you have already moved extraction onto ODP over OData or onto SAP's newer delivery paths, do not assume the RFC modules went away with the old design. We would check whether the components are present and callable rather than reason from an architecture diagram, because the connections between a data platform and a ledger are usually the ones nobody redrew.
Silence in the report is not a pass
The new check appears only when ODP activity is detected. A system with no detected activity produces no finding, and no finding reads as green to anyone skimming a management summary. Those two results are far from equivalent, and the difference is the kind of nuance a summary page flattens.
An absent finding can mean the system genuinely does no ODP extraction. It can also mean a monthly or quarterly load fell outside whatever window the check samples, or that your EarlyWatch content has not picked up the new check yet. Say that in the meeting where the report gets reviewed, before someone types 'no ODP findings' into a status slide and it becomes the official position.
The order to check things in
Start with whether you extract over ODP-RFC at all. The answer lives in your RFC destinations, in the source systems registered in BW, and in whatever extraction tool sits on top. It does not live in anyone's recollection of the integration, so ask for the actual list of destinations and the service users behind them.
Then confirm whether the listed components are present at the listed versions. That is a component version check, and it takes a few minutes per system. Run it everywhere in the estate, including systems nobody thinks of as data sources, because old regression and sandbox systems keep working copies of production extractors.
Then check patch status rather than assuming the June patch day went in cleanly. Notes get deferred with a business justification nobody revisits, and a Medium landing alongside higher-priority items is the classic candidate for deferral. Our guide to ranking patches when everything looks urgent and our read on SAP's maintenance calendar both assume the queue is where risk accumulates.
What we could not confirm
We could not read the blog post body. Four retrieval attempts returned an access error, so the September date and the attribution to SAP come from SAP's own feed, while the technical detail above rests on SAP's security note page and public vulnerability databases. There are no quotes and no named author, so this is attributed to SAP as publisher of the community post.
Sources disagree on the exact disclosure date, with SAP's patch page and a vulnerability tracker two days apart, so we say June 2026 patch day and give no single date. Surrounding reporting describes an opt-out for the new check that ends during 2026. We could not confirm that, and we are withholding the report name, the opt-out note number and the expiry month, because each came from a single source.
If you want the opt-out mechanics, get them from SAP directly rather than from secondary coverage, ours included. Then do the three things that settle it. Pull the list of RFC destinations used for ODP extraction, run a component version check against DW4CORE, PI BASIS and SAP BW on every connected system, and confirm note 3748819 is applied before the next EarlyWatch Alert goes out.
