[kali834x]

the addressing-phase AddressingBasedDispatcher.invoke now binds the service from the To, and the operation from wsa:Action, when a wsa:RelatesTo correlates to no operation context. that dispatch sat in the else of "a RelatesTo is present", so an uncorrelated RelatesTo skipped it and RequestURIBasedDispatcher in the Dispatch phase bound the service from the same To, which AddressingInHandler has already replaced with the wsa:To header, after the Security phase had run with no service. handlers of a module engaged on one service sit in the global Security phase and gate on MessageContext.isEngaged, which is false while nothing is bound, so an anonymous POST to /axis2/services/ carrying wsa:To naming a protected service, its wsa:Action and any wsa:RelatesTo reached the operation without them running (CWE-863). this is the late binding SECURITY.md item 13 describes for content-based dispatch, and it is why that item's line about WS-Addressing dispatch binding before Security did not hold. a correlated RelatesTo, a message that already has an operation context, and messages without a RelatesTo are unchanged, and the uncorrelated case gets no ActionNotSupported check, since replies and faults sent on to a ReplyTo/FaultTo carry such a RelatesTo with an action their endpoint need not map (testFaultToFaultTo in the integration addressing tests fails if it is added). not verified here: whether Rampart's PostDispatchVerificationHandler already refuses such a message for Rampart itself; other service-scoped Security-phase handlers have no such backstop. AddressingBasedDispatcherTest gains a case that fails before the change, and an AxisEngine.receive run with the real AddressingInHandler and a service-engaged Security-phase handler showed the handler skipped and the operation invoked before, the message refused after. kernel (498 tests) and addressing (66) verify with -Papache-release, and the full integration suite (244), pass.