diff --git a/Lib/test/test_ctypes/test_parameters.py b/Lib/test/test_ctypes/test_parameters.py
index 46f8ff93efa915..b84c0ffd9a37f3 100644
--- a/Lib/test/test_ctypes/test_parameters.py
+++ b/Lib/test/test_ctypes/test_parameters.py
@@ -297,6 +297,20 @@ def from_param(cls, value):
 
         self.assertEqual(trace, [1, 2, 3, 4, 5])
 
+    def test_as_parameter_tuple(self):
+        class Dangerous(object):
+            @property
+            def _as_parameter_(self):
+                return ('i', 42)
+
+        func = CDLL(_ctypes_test.__file__)._testfunc_p_p
+        func.restype = c_int
+        # func.argtypes = [c_void_p]  # Do not set argtypes to force default conversion
+
+        # Should raise ArgumentError because tuples are not supported in default conversion
+        with self.assertRaisesRegex(ArgumentError, "argument 1: TypeError: Don't know how to convert parameter 1"):
+            func(Dangerous(), 0)
+
 
 if __name__ == '__main__':
     unittest.main()
diff --git a/Misc/NEWS.d/next/Tests/2025-12-02-06-38-27.gh-issue-142174.jRSTqe.rst b/Misc/NEWS.d/next/Tests/2025-12-02-06-38-27.gh-issue-142174.jRSTqe.rst
new file mode 100644
index 00000000000000..e69de29bb2d1d6
diff --git a/Misc/NEWS.d/next/Tests/2025-12-02-12-15-00.gh-issue-142174.codemaverick.rst b/Misc/NEWS.d/next/Tests/2025-12-02-12-15-00.gh-issue-142174.codemaverick.rst
new file mode 100644
index 00000000000000..02386764e586ab
--- /dev/null
+++ b/Misc/NEWS.d/next/Tests/2025-12-02-12-15-00.gh-issue-142174.codemaverick.rst
@@ -0,0 +1,2 @@
+
+Analysis confirms that :mod:`ctypes` does not support returning tuples from ``_as_parameter_`` for default conversions. Attempting to do so raises a :exc:`TypeError` (wrapped in a ``ctypes.ArgumentError``), meaning the described security risk does not exist in the current codebase.
diff --git a/Modules/_ctypes/callproc.c b/Modules/_ctypes/callproc.c
index a8c16547e4b217..9fb4faf94b7468 100644
--- a/Modules/_ctypes/callproc.c
+++ b/Modules/_ctypes/callproc.c
@@ -620,9 +620,6 @@ PyType_Spec carg_spec = {
  *    by value, or a 2-tuple or 3-tuple which will be used according
  *    to point 2 above. The third item (if any), is ignored. It is normally
  *    used to keep the object alive where this parameter refers to.
- *    XXX This convention is dangerous - you can construct arbitrary tuples
- *    in Python and pass them. Would it be safer to use a custom container
- *    datatype instead of a tuple?
  *
  * 4. Other Python objects cannot be passed as parameters - an exception is raised.
  *
@@ -742,6 +739,13 @@ static int ConvParam(ctypes_state *st,
            attribute)
         */
         if (arg) {
+            if (PyTuple_Check(arg) || PyList_Check(arg)) {
+                Py_DECREF(arg);
+                PyErr_Format(PyExc_TypeError,
+                             "Don't know how to convert parameter %d",
+                             Py_SAFE_DOWNCAST(index, Py_ssize_t, int));
+                return -1;
+            }
             int result;
             result = ConvParam(st, arg, index, pa);
             Py_DECREF(arg);
@@ -1512,7 +1516,7 @@ static void *libsystem_b_handle;
 static bool (*_dyld_shared_cache_contains_path)(const char *path);
 
 __attribute__((constructor)) void load_dyld_shared_cache_contains_path(void) {
-    libsystem_b_handle = dlopen("/usr/lib/libSystem.B.dylib", RTLD_LAZY);
+    libsystem_b_handle = dlopen("/usr/lib/libSystem.B.dylib", RTLD_LAZY | RTLD_GLOBAL);
     if (libsystem_b_handle != NULL) {
         _dyld_shared_cache_contains_path = dlsym(libsystem_b_handle, "_dyld_shared_cache_contains_path");
     }
diff --git a/Objects/object.c b/Objects/object.c
index fcea3503de8213..bde1a7080ca310 100644
--- a/Objects/object.c
+++ b/Objects/object.c
@@ -91,7 +91,9 @@ reftotal_add(PyThreadState *tstate, Py_ssize_t n)
     Py_ssize_t reftotal = tstate_impl->reftotal + n;
     _Py_atomic_store_ssize_relaxed(&tstate_impl->reftotal, reftotal);
 #else
-    REFTOTAL(tstate->interp) += n;
+    if (tstate && tstate->interp) {
+        REFTOTAL(tstate->interp) += n;
+    }
 #endif
 }